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

[Guido van Rossum]

On 3/15/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

Well, also absolute imports when the future statement is in effect --
__import__ needs to know whether to interpret "import foo" as "first
try __path__, then sys.path" or as "only look in sys.path".

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

How would the conversion be done? The compiler can't tell whether a
classic "import foo" is intended to be a relative or absolute import.

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

Yes, but it would defeat the purpose of import hooks -- import hooks
need to be able to assign their own semantics. (Long, long ago, there
was no built-in support for packages, but you could install an import
hook that enabled it.)

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

I think so. Import hooks requires a lot of careful work. Requiring
import hooks to be explicitly ported probably provides better
guarantees that they actually work.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)