adopt flake8-tidy-imports to enforce O.1.5 #223
+49
−10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reason
We have O.1.5 which says:
We don't have enforcement of this.
If a non-absolute import is used, our current tooling (
fix
andformat) has different behavior depending on if it is run above the module (in the folder with
pyproject.toml) or in a sub-folder within the module. This is (in part) caused by us setting the
app-import-names` automatically if the user does not specify it. (and we don't include neighbor sub-modules).This PR is a way to address
#215
Adopting
flake8-tidy-imports
+ explicitly setting it to ban "all relative" imports, the case mentioned in that issue is dealt with by flagging that "neighbor" import with I252.Pros:
Simple, opinionated rule
Cons:
(this example assumes a layout similar to):
As PEP328 defines it, if the import "import foo" is present, it is considered to be an absolute import (even though the intention is to resolve to a neighboring sub-module); while, "import .foo" or "from . import foo" are both relative imports.
As
flake8-tidy-imports
is currently implemented, this would also ban an "absolute" import that is meant to resolve to a neighbor.Rationale:
fizz.py
is ambiguous for human readers. Do we wantmodule.foo
? or shouldfoo
be coming from an install-time dep?subprocess
sub-module, the codeimport subprocess
would resolve to this module's subprocess even if it was intended to resolve to stdlib. By adding this rule in, that would now be required to beimport module.subprocess
orfrom module import subprocess
.module
) makes it clear that this is "first-party" and removes ambiguity over whether iSort is doing the right thing or not.