-
Notifications
You must be signed in to change notification settings - Fork 179
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
Always report imports shadowed by another import #45
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -184,9 +184,8 @@ def bar(): | |
def baz(): | ||
def fu(): | ||
pass | ||
''', | ||
m.RedefinedWhileUnused, m.RedefinedWhileUnused, | ||
m.UnusedImport, m.UnusedImport) | ||
''', *(m.ImportShadowedByImport, m.RedefinedWhileUnused, | ||
m.UnusedImport, m.UnusedImport)) | ||
|
||
def test_redefinedButUsedLater(self): | ||
""" | ||
|
@@ -564,6 +563,15 @@ def bar(): | |
fu | ||
''', m.UnusedImport, m.UndefinedName) | ||
|
||
def test_shadowedInNestedScope(self): | ||
self.flakes(''' | ||
import fu | ||
def bar(): | ||
import fu | ||
fu | ||
fu | ||
''', m.ImportShadowedByImport) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I agree this is a desirable behavior. I know there's also an
There's nothing inherently erroneous about the code here. Can we be sure that no one will ever have a legitimate reason to do this? What if we change the example a bit: from StringIO import StringIO
def bar():
from cStringIO import StringIO
StringIO
StringIO There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unused imports is also style, not an error. I could exlude ast.ImportFrom from this new rule to avoid some scenarios where redefining an imported name is less problematic, such as your example. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That could work. Though, #44 makes me think of another case: import foo
class bar:
import foo
foo Probably there should be no errors here, but right now it looks like the 2nd There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Differentiating between types of imports will be much cleaner and simpler after #54 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But this isn't even bad style. It's no different from
Redefining variables in inner scopes is a perfectly legitimate thing to do, whether that be via imports, loops, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO it isnt the same, as imports are an external resource, and should be consistently named through the module. I can appreciate if others think that is too much a style issue for pyflakes to take on. However, the case I am most interested in is
Currently that isnt caught as a redefinition because There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just noting that in the case of the class attribute, the same can be achieved without shadowing using
But as said earlier, I am happy to allow shadowing for class attributes, and other instances if there is consensus one way or the other. |
||
|
||
def test_methodsDontUseClassScope(self): | ||
self.flakes(''' | ||
class bar: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the use of the
*(...)
construction here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To simplify neater indentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, this isn't exactly clear or obvious. I understand why, but I'm not sure I agree with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries; I can rework it when I create a narrower patch after #54 has been approved.