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

[Serhiy Storchaka]

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 affect 
existing code which does not use this builting, but all will be changed if 
implement this feature.

Since shadowing a builtin and overwriting an existing global is not always an 
error, I think this warning should not be the part of the interpreter, but 
rather a part of third-party linters (which can be configured to ignore some 
warnings for particular projects).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Windson Yang]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 get".

>>> from os import *
Warning (from warnings module):
  File "__main__", line 1
ImportWarning: The 'open' variable in the 'os' module shadows a variable in the 
'builtins' module

>>> alpha = 2.0
>>> beta = 3.0
>>> gamma = 4.5
>>> delta = 5.5
>>> from math import *
>>> from os import *
Warning (from warnings module):
  File "__main__", line 8
ImportWarning: The 'gamma' variable in the 'math' overwrites an existing 
variable in the globals.

--
components: Interpreter Core
messages: 341166
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Teach "import *" to warn when overwriting globals or builtins
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com