Skip to content

Finish linting on py3ish code #2949

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Jun 14, 2017
Merged

Finish linting on py3ish code #2949

merged 15 commits into from
Jun 14, 2017

Conversation

agjohnson
Copy link
Contributor

@agjohnson agjohnson commented Jun 13, 2017

This merges in #2863 and #2938, and fixes the rest of the linting problems introduced with #2819. Most of these errors with ordering of imports. The problem with using future, and the includes builtins with future, is that these both cause a number of linting problems. The standard library mocking needs to be at the bottom of the import block, otherwise all the following import statements are considered out of order.

This work normalizes the import order to (mostly) follow pep8:

  • Python builtins
  • Third party (including builtins, which is third party even though it overrides standard imports
  • Local packages
  • Standard library overrides with future, each import needs a # noqa to avoid errors on not being able to find the import (as it's just monkey patched via future)

This also updated our travis config to test with the correct Python version.

Most important here are the last of the commits to this branch, following d2599ba. The other work is available in other PRs.

CM Lubinski and others added 15 commits June 9, 2017 08:56
This is a first step and only adds docstrings, etc. It doesn't refactor any
code.

Conflicts:
	prospector-more.yml
	readthedocs/restapi/views/model_views.py
In several cases, we can use the provided `request` rather than access `self`
(which could make these functions easier to test in isolation). In others, the
unused args could be folded into an unnamed kwarg param.
This worked as intended, but only because the overridden section variable
would later evaluate to True. Using a different variable name makes this a bit
less error-prone.
Fix linting problems with restapi application
This addresses no-else-return, which removes a `return` in an `else` after an
`if` that already has a `return`. This makes the default return more obvious in
most cases.
Conflicts:
	readthedocs/profiles/views.py
	readthedocs/restapi/client.py
	readthedocs/restapi/permissions.py
	readthedocs/restapi/serializers.py
	readthedocs/restapi/signals.py
	readthedocs/restapi/urls.py
	readthedocs/restapi/utils.py
	readthedocs/restapi/views/core_views.py
	readthedocs/restapi/views/footer_views.py
	readthedocs/restapi/views/integrations.py
	readthedocs/restapi/views/model_views.py
	readthedocs/restapi/views/search_views.py
	readthedocs/restapi/views/task_views.py
	requirements/lint.txt
Also, update travis and tox config for multiple versions of python
@agjohnson agjohnson added the PR: work in progress Pull request is not ready for full review label Jun 13, 2017
@agjohnson agjohnson requested a review from ericholscher June 13, 2017 23:35
Copy link
Member

@ericholscher ericholscher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. 💯

@agjohnson
Copy link
Contributor Author

I think i got all the calls that future was overriding, but it might be a good idea to have @gthank look at the imports that were shuffled. The only thing I don't like about future is it's magical and it's not explicit about what is being monkeypatched -- six, although verbose, was clear in its magic.

include:
- python: 2.7
env: TOXENV=docs
- python: 2.7
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is lint different on 2 or 3, should we be linting both languages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I was going to say bump linting and docs steps up to py3 when our code is ready. I don't know if bumping up before then would yield any unwarranted effects or not from the code not being quiet py3 compatible.

Copy link
Member

@ericholscher ericholscher Jun 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

@agjohnson agjohnson merged commit accc015 into gthank-master Jun 14, 2017
@agjohnson agjohnson removed the PR: work in progress Pull request is not ready for full review label Jun 14, 2017
@stsewd stsewd deleted the py3-lint-fixes branch August 15, 2018 22:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants