This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: move __import__() out of the default lookup chain
Type: behavior Stage: needs patch
Components: Interpreter Core Versions: Python 3.4
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, benjamin.peterson, brett.cannon, eric.araujo, eric.snow, georg.brandl, r.david.murray
Priority: low Keywords:

Created on 2012-08-18 03:38 by eric.snow, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg168493 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-08-18 03:38
When people want to import modules with "runtime" names, they regrettably turn to __import__(), have done so for many years, and likely will for a while.

If it were less convenient to use __import__(), fewer people would use it.  I'm putting together a patch that removes it from <module>.__builtins__, so that it will not be found during normal name lookup.  However, it will still available for the adventurous spirit via the imp module, following the precedent of reload().

This proposal came up in issue15715.
msg168497 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-08-18 06:17
Ah, __import__() is used all over the place in the stdlib.  I won't have time right away to put together the patch then.  However, here's what I'm planning:

* expose builtin___import__() (from Python/bltinmodule.c) as imp.__import__().
* expose one used by the interpreter as builtins.__import__(), thus keeping it replaceable.
* hide it in <module globals>.__builtins__.

That last part is the tricky part, and has a bit of a smell to it...  Simply removing it from builtins would be easiest, but that still seems like the right place to go when you want to replace it with your own flashy __import__().

Insight appreciated, but this is definitely low priority at least for the next few months.
msg168512 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-08-18 13:29
I could be wrong, but it is hard for me to see how we could justify doing this before python4, at this point in python3.

Adding a warning would be uncontroversial, though.
msg169168 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-08-26 18:51
I agree with David.
msg169176 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2012-08-27 03:26
Definitely "won't fix" until at least Python 4.
History
Date User Action Args
2022-04-11 14:57:34adminsetgithub: 59925
2012-08-27 03:26:29benjamin.petersonsetstatus: open -> closed

nosy: + benjamin.peterson
messages: + msg169176

resolution: not a bug
2012-08-26 18:51:03georg.brandlsetnosy: + georg.brandl
messages: + msg169168
2012-08-26 02:31:53eric.araujosetnosy: + eric.araujo
2012-08-18 13:30:37Arfreversetnosy: + Arfrever
2012-08-18 13:29:57r.david.murraysetnosy: + r.david.murray
messages: + msg168512
2012-08-18 06:17:55eric.snowsetpriority: normal -> low

messages: + msg168497
2012-08-18 03:38:08eric.snowcreate