[Python-ideas] Packages and Import

Ron Adam rrr at ronadam.com
Thu Feb 8 19:31:49 CET 2007

Adam Olsen wrote:
> On 2/4/07, Ron Adam <rrr at ronadam.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.

Seems to me, weather the importer is part of this module or the new module 
doesn't make a difference.  Just a matter of ordering.

So if you want to modify the import mechanism:

Would create a new ModuleType and modify it's import mechansims and then pass it 
a name?

Or would it be better to subclass this modules import, modify it, pass it along 
with a name (to be imported) to the new ModuleType?

Or modify this modules import and then subclass this ModuleType, which will 
inherit the new importer.  So that ModuleType(__name__) will then initialize it 
self?  (but this would inherit a lot of other things you may not want.)

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

Then you are further along than I am.

I just know what I want it to do.  But I am trying to learn about how the actual 
imports function.  Maybe in a few days I can give Brett some suggestions that 
are a little more concrete.


More information about the Python-ideas mailing list