On 3/15/06, Phillip J. Eby <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
