On 2/4/07, Ron Adam firstname.lastname@example.org wrote:
After exploring this a bit further on comp.lang.python, I was able to organize these ideas better. The more I thought about it, the more '+'s I found, and about the only '-'s I can think of is the work required to actually make a patch to do it.
It's also good to keep in mind that since most people still rely on the old relative import behavior, most people have not run into some of the issues I mention here. But they will at some point.
I did mean to keep this short, but clarity won out. (At least it's clear to me, but that's an entirely subjective opinion on my part.)
Maybe someone will adopt this and make a real PEP out of it. :-)
For all the complexity of module attributes and global import hooks I think there's something that'll start to strip some of it away: make __import__() into a method of ModuleType, then ensure there's a way to load python modules using subclasses of ModuleType.
You could have entirely different semantics, independent of sys.modules. You could load from a zip file that's entirely private, while still allowing modules within it to reach each other using relative imports.
Once you break free of sys.modules and global hooks it becomes much easier to design something to replace them.
I have some ideas on how to do that, but they don't seem nearly as important as this base functionality.