[issue36762] Teach "import *" to warn when overwriting globals or builtins

Serhiy Storchaka added the comment: This will force legal third-party code to add special code to suppress warnings. This is breaking change. Other problem is with shadowing builtins. This increases chance of breakage when introduce new builtins. Currently adding a new builtin does not affec

[issue36762] Teach "import *" to warn when overwriting globals or builtins

Windson Yang added the comment: Another question will be are we going to replace the * in our source code in the future? Since I found lots of our code use 'from xxx import *' pattern. -- nosy: +Windson Yang ___ Python tracker

[issue36762] Teach "import *" to warn when overwriting globals or builtins

Raymond Hettinger added the comment: > What if existing globals are overwritten intentionally? That's why it would be a warning instead of an error. Also, with warnings we can suppress specific instances (by module or by message). -- ___ Python t

[issue36762] Teach "import *" to warn when overwriting globals or builtins

Serhiy Storchaka added the comment: What if existing globals are overwritten intentionally? For example, the stat module defines some constant and then use the star import from _stat. Other example is the datetime module. -- nosy: +serhiy.storchaka __

[issue36762] Teach "import *" to warn when overwriting globals or builtins

New submission from Raymond Hettinger : One reason we usually suggest that people don't use star imports is that it is too easy to shadow a builtin or overwrite an existing global. Momma Gump always used to say, "import star is like a box of chocolates, you never know what you've going to ge