Shadows name from outer scope python что
Shadows name xyz from outer scope
I am using pycharm and it lists out all the errors/warnings associated with the code. While I understand most of them I am not sure of this one «Shadows name xyz from outer scope». There are a few SO posts regarding this: How bad is shadowing names defined in outer scopes? but then they seem to be accessing a global variable.
In my case, my __main__ function has a few variable names and then it is calling another function sample_func which uses those variable names again (primarily the loop variable names). I am assuming because I am in a different function, the scope for these variables will be local, however the warning seem to suggest otherwise.
Any thoughts? For your reference here is some code:
5 Answers 5
The warning is about the potential danger you are introducing by re-using these names at inner scopes. It can cause you to miss a bug. For example, consider this
Because you used the same name, your misspelling inside the function does not cause an error.
When your code is very simple, you will get away with this type of thing with no consequences. But it’s good to use these «best practices» in order to avoid mistakes on more complex code.
The code inside of your if branch of your main function is actually in scope when you’re inside of sample_func. You can read from the variable x (try it out). This is okay as you don’t really care about it so you have a few options to move forward.
1) Disable shadowing warnings in pycharm. Honestly this is the most straightforward and depending on how experienced of a coder you are it probably makes the most sense (if you’re relatively new I would not do this though.)
2) Put your main code into a main function. This is probably the best solution for any production level code. Python is very good at doing things the way you want to do them so you should be careful not to fall into traps. If you are building a module, having lots of logic at the module level can get you into sticky situations. Instead, something like the following could be helpful:
3) Don’t use the same variable names that you’re using in broader scopes. This is pretty hard to enforce and is kinda the opposite of #1.
What is the problem with shadowing names defined in outer scopes?
I just switched to PyCharm and I am very happy about all the warnings and hints it provides me to improve my code. Except for this one which I don’t understand:
This inspection detects shadowing names defined in outer scopes.
I know it is bad practice to access variable from the outer scope, but what is the problem with shadowing the outer scope?
Here is one example, where PyCharm gives me the warning message:
9 Answers 9
Finally, built-in functions and types also live in the same namespace and can be shadowed the same way.
None of this is much of a problem if you have short functions, good naming and a decent unit test coverage, but well, sometimes you have to maintain less than perfect code and being warned about such possible issues might help.
It doesn’t matter how long your function is, or how you name your variable descriptively (to hopefully minimize the chance of potential name collision).
The fact that your function’s local variable or its parameter happens to share a name in the global scope is completely irrelevant. And in fact, no matter how carefully you choose you local variable name, your function can never foresee «whether my cool name yadda will also be used as a global variable in future?». The solution? Simply don’t worry about that! The correct mindset is to design your function to consume input from and only from its parameters in signature. That way you don’t need to care what is (or will be) in global scope, and then shadowing becomes not an issue at all.
In other words, the shadowing problem only matters when your function need to use the same name local variable and the global variable. But you should avoid such design in the first place. The OP’s code does not really have such design problem. It is just that PyCharm is not smart enough and it gives out a warning just in case. So, just to make PyCharm happy, and also make our code clean, see this solution quoting from silyevsk’s answer to remove the global variable completely.
This is the proper way to «solve» this problem, by fixing/removing your global thing, not adjusting your current local function.
Все, что вы хотели узнать про области видимости в Python, но стеснялись спросить
В преддверии старта нового потока по курсу «Разработчик Python», решили поговорить про области видимости в Python. Что из этого вышло? — Читайте в материале ниже.
Сегодня мы будем говорить о важных теоретических основах, которые необходимо понимать и помнить, чтобы писать грамотный, читаемый и красивый код. Мы будем вести речь об областях видимости переменных. Эта статья будет полезна не только новичкам, но и опытным программистам, которые пришли в Python из другого языка и хотят разобраться с его механиками работы.
Области видимости определяют, в какой части программы мы можем работать с той или иной переменной, а от каких переменная «скрыта». Крайне важно понимать, как использовать только те значения и переменные, которые нам нужны, и как интерпретатор языка себя при этом ведет. А еще мы посмотрим, как обходить ограничения, накладываемые областями видимости на действия с переменными. В Python существует целых 3 области видимости:
Обычно, речь заходит про области видимости, когда происходит знакомство с функциями. На их примере мы и будем рассматривать работу областей видимости переменных.
Локальная область видимости
Рассмотрим функцию, которая выведет список some_list поэлементно:
Теперь мы поступим следующим образом:
Здесь переменная element внутри функции и переменная с таким же именем вне ее – это две разные переменные, их значения не перекрещиваются и не взаимозаменяются. Они называются одинаково, но ссылаются на разные объекты в памяти. Более того, переменная с именем element внутри функции живет столько же, сколько выполняется функция и не больше. Но будьте аккуратны с тем, чтобы давать локальным и глобальным переменным одинаковые имена, сейчас покажу почему:
Обратите внимание на то, что интерпретатор не указал нам на ошибки. А все потому что sudden_list находится в глобальной области видимости, то есть изнутри функции print_list мы можем к нему обращаться, поскольку изнутри видно то, что происходит снаружи. По причине таких механик работы старайтесь называть локальные переменные внутри функции не так, как называете переменные в глобальной области видимости.
Здесь важно поговорить о константах. Интерпретатору Python нет разницы как вы называете переменную, поэтому код выше будет лучше переписать в следующем виде:
Теперь все на своих местах. Дело в том, что в Python нельзя каким-то образом строго определить константу, как объект, который не должен быть изменен. Так что то, как вы используете значение переменной, имя которой записано заглавными буквами, остается лишь на вашей совести. Другой вопрос, что таким способом записанная переменная даст понять тому, кто будет читать ваш код, что переменная нигде изменяться не будет. Или по крайней мере не должна.
Глобальная область видимости
В результате получим:
Однако менять значение глобальной переменной изнутри функции – не лучшая практика и лучше так не делать, поскольку читаемости кода это не способствует. Чем меньше то, что происходит внутри функции будет зависеть от глобальной области видимости, тем лучше.
Нелокальная область видимости
Насколько это полезно вам предстоит решить самостоятельно. Больше примеров вы можете найти здесь.
В качестве вывода можно сформулировать несколько правил:
Насколько плохо теневые имена определены во внешних областях?
Я только что переключился на Pycharm, и я очень рад всем предупреждениям и подсказкам, которые он дает мне для улучшения моего кода. За исключением этого, которое я не понимаю:
This inspection detects shadowing names defined in outer scopes.
Я знаю, что это плохая практика для доступа к переменной из внешней области, но в чем проблема с затенением внешней области?
Вот один пример, где Pycharm дает мне предупреждающее сообщение:
Наконец, встроенные функции и типы также находятся в одном и том же пространстве имен и могут быть затенены одинаково.
Ничего из этого не представляет большой проблемы, если у вас короткие функции, хорошее наименование и приличное покрытие юнит-тестами, но иногда вам приходится поддерживать не совсем идеальный код, и может помочь предупреждение о таких возможных проблемах.
Неважно, какова длина вашей функции или как вы называете переменную описательно (чтобы минимизировать вероятность потенциального конфликта имен).
Другими словами, проблема теневого копирования имеет значение только тогда, когда вашей функции необходимо использовать локальную переменную с тем же именем И глобальную переменную. Но вы должны избегать такого дизайна в первую очередь. Код OP на самом деле не имеет такой проблемы дизайна. Просто PyCharm недостаточно умен и выдает предупреждение на всякий случай. Итак, просто чтобы порадовать PyCharm, а также сделать наш код чистым, посмотрите, как это решение цитирует ответ Сильевска на полное удаление глобальной переменной.
Это правильный способ «решить» эту проблему, исправляя / удаляя вашу глобальную вещь, а не настраивая текущую локальную функцию.
Why and how to resolve shadows argument name from outer scope in class (python)?
Pycharm, Python 3.8
2 Answers 2
As others have explained, you have two variables called some_val which could technically be visible in the same part of the code; PyCharm is warning you about this because it can be confusing to have two different variables with the same name.
In this case, the solution is to put the code after if __name__ == ‘__main__’ into a function, and only have a call to that function after the if ; that moves the variables used in that section of the code into a local scope, so they won’t be confused with variables elsewhere:
You could also do this only partially, like this:
The method _test makes no use of the self parameter.
If that’s what’s intended, you can mark it as @staticmethod and omit the self :
Alternately, expand the method so that it does, in fact, use self (which you may have been planning to do in any case).
You have declared a some_val variable in you global scope:
Since this variable is global, it is normally accessible from anywhere in the module.
But your Test._test1 and Test.main methods define some_val arguments which are accessible only from the methods body: they are in the methods local scopes.
This warning simply informs you that the some_val parameters are hiding («shadowing») the some_val global variable, and that you won’t be able to access the global variable from the method body (since some_val will refer to the local parameter).
Technically, if you don’t need to access the global some_val variable from the methods body, it is not a problem.
You can fix this warning by simply giving better names to your variables/parameters, and not reusing same names for global and local variables.
This warning means that, since your Test1._test method does not use the self argument, it could be declared as static using the staticmethod decorator (see more details in this other SO question):