[Python-Dev] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py

[Phillip J. Eby]

At 01:34 PM 3/15/2006 -0800, Guido van Rossum wrote:
>Because Thomas designed it this way. :-)
>
>I believe his design makes sense though: "import foo" translates to
>__import__(foo, ...).
>
>There's a separate setting, only known to the compiler, that says
>whether "from __future__ import absolute_import" is in effect (there's
>no way to slip a flag into globals to convey this setting, since code
>is compiled independently from globals, and there are ways to pass
>flags to the compiler without explicitly doing the future import).
>
>So the compiler emits different code when the future syntax is in
>effect, and that opcode must pass its knowledge to __import__. This is
>done trough the 5th argument, which also tells us how many leading
>dots there were. Without the future import, the 5th argument is
>omitted (as long as there aren't any leading dots).

Ah, so it's *relative* imports that require a 5th argument.  I was thinking 
it was there to support absolute imports.  I was thinking that relative 
imports could be implemented by popping bits off of __name__ to get an 
absolute location.

It seems to me that backward compatibility would be greatly enhanced by 
having the interpreter convert everything but "legacy" imports into 
absolute imports, as this would then work with the existing __import__ code 
in the field, even when new relative/absolute code was doing the 
importing.  Otherwise, this forces __import__ hooks to be rewritten.  (I 
personally avoid writing __import__ hooks if at all possible, but there are 
certainly some out there.)

The mechanism I have in mind would be to just have an IMPORT_EXACT opcode 
that takes a relative or absolute name.  This opcode would process relative 
names relative to the __name__ in globals to produce an exact module name, 
and leave absolute names alone.  It would then invoke __import__ using the 
builtins or sys module dictionary as the "globals" argument *instead of the 
current globals*, so that __import__ will not do any legacy-style fallback.

When absolute imports are in effect, or when an explicit relative import is 
used, it would be compiled such that IMPORT_NAME is replaced by IMPORT_EXACT.

This mechanism doesn't require any change to the __import__() signature, 
and so remains backward compatible with any existing import hook that 
doesn't do weird things to the globals dictionary of the module that 
invoked it.

On the other hand, perhaps it would be better to fail loudly by breaking on 
the 5th argument, than to fail silently for really weird __import__ 
hooks.  That is, if it breaks, it will force people to make sure their 
__import__ code is safe for use with absolute imports.  So, the existing 
approach might well be better than what I had in mind.