Closed sobolevn closed 5 years ago
That's easy - 2. You just start from local context and getting through outer ones until hit globals. Your example is too syntetic, but consider this one:
def any(thing):
thing = some(thing)
def no(thing):
pass
return no(thing)
We want to explicitly pass thing
to inner no function, but it still named the same because it means the same outer one. Is that wrong?
Yes, it is. There's no need to:
Well, if you forbid point 1, I don't see any cases when this issue may exists. However, there would be need to detect decorator-functions. But their pattern +/- quite oblivious.
@kxepal we already forbid most nested functions except decorator
and factory
functions. See https://wemake-python-styleguide.readthedocs.io/en/latest/pages/violations/best_practices.html#wemake_python_styleguide.violations.best_practices.NestedFunctionViolation
Awesome! Than that this issue shouldn't be an issue at all. What's the case?
For decorator
and factory
functions that can be nested 🙂
And also someone can use # noqa
to disable the nested function violation. But, we still will be able to find other possible errors.
But only for one (simple decorators) or two levels (paratetrized decorators). Nothing deeper and there closure is used to by pass arguments, so no shadowing happens.
Do you have rule to forbid # noqa
commetaries? That should be helpful.
Yes, I have a plan to forbid too many noqa
comments.
The same should also work for this case:
def factory(factory):
def factory():
factory = 1
There are three violations here:
We can also shadow attributes and methods:
class Test(object):
some = 1
def some():
...
Import shadowing is already handled by flake8
.
Related #399
I will close this issue in order to work on #399 with bigger scope.
Rule request
Thesis
We can shadow names when using nested functions. Like in this example:
Can you tell what will be printed from the first sight?
Reasoning
Name shadowing can be very tricky. And it will cause different errors in your code. We need to prevent that.