On 2/8/07, Adam Olsen firstname.lastname@example.org wrote:
On 2/4/07, Ron Adam email@example.com 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.
And so __import__ is to be bound to what module's method? Or is it a class method?
You could have entirely different semantics, independent of sys.modules.
You can have that now if you ignored 'reload'. You just need to delete a module from sys.modules as soon as you import. Then you can set up your imports to do what you want.
You could load from a zip file that's entirely private, while still allowing modules within it to reach each other using relative imports.
So are you saying that imports in a module are to use the module's __import__ method? So instantiate a module and then use it's method to initialize the module itself?