Teach "import *" to warn when overwriting globals or builtins

[rhettinger]

BPO	36762
Nosy	@rhettinger, @serhiy-storchaka, @Windsooon

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-04-30.22:31:42.781>
labels = ['interpreter-core', 'type-bug', '3.8']
title = 'Teach "import *" to warn when overwriting globals or builtins'
updated_at = <Date 2019-05-02.04:56:17.488>
user = 'https://github.com/rhettinger'

bugs.python.org fields:

activity = <Date 2019-05-02.04:56:17.488>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2019-04-30.22:31:42.781>
creator = 'rhettinger'
dependencies = []
files = []
hgrepos = []
issue_num = 36762
keywords = []
message_count = 5.0
messages = ['341166', '341229', '341237', '341243', '341247']
nosy_count = 3.0
nosy_names = ['rhettinger', 'serhiy.storchaka', 'Windson Yang']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue36762'
versions = ['Python 3.8']

[rhettinger]

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.

[serhiy-storchaka]

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.

[rhettinger]

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).

[Windsooon]

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.

[serhiy-storchaka]

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).

[iritkatriel]

I agree with @serhiy-storchaka 's objections.