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.

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.

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.

I agree with David.

Definitely "won't fix" until at least Python 4.