[Python-Dev] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/init.py (original) (raw)

Guido van Rossum guido at python.org
Wed Mar 15 23:25:14 CET 2006

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 IMPORTEXACT 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 IMPORTNAME is replaced by IMPORTEXACT.

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

More information about the Python-Dev mailing list