On 28. 03. 22 15:25, Irit Katriel via Python-Dev wrote:
If you have a __future__ import in a script, and you import * from it in another script, the object for this future appears in the dir() of the other script, even though the __future__ import has no effect there.
% cat x.py from __future__ import annotations
% cat y.py from x import *
print(dir())
class D: def f(self, a: D): return 42
% ./python.exe y.py ['__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '*annotations*'] Traceback (most recent call last): File "/Users/iritkatriel/src/cpython-654/y.py", line 5, in <module> class D: ^^^^^^^^ File "/Users/iritkatriel/src/cpython-654/y.py", line 6, in D def f(self, a: D): ^
NameError: name 'D' is not defined
I think we should change import * to exclude the __future__ import objects, and perhaps also to not show them in dir(x). Any objections?
This came up in the discussion about https://bugs.python.org/issue26120 <https://bugs.python.org/issue26120> . See the attached PR for a technique we can use to identify those objects.
__future__ imports are just one way to put garbage in the global namespace. I don't think they should be handled specially. IMO, it would be better to document the current best practice that `import *` should only be used with modules designed for `import *` (by setting `__all__`; carefully `del`-ing what they don't want to export might work too but it's fragile), or when you don't care about namespace pollution (e.g. in interactive sessions).