[Python-checkins] r52292 - sandbox/trunk/import_in_py/importer.py

[Brett Cannon]

On 10/13/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> Brett Cannon wrote:
> > On 10/13/06, *Nick Coghlan* <ncoghlan at gmail.com
> > <mailto:ncoghlan at gmail.com>> wrote:
> >     Go with the generalization - there are existing application toolkits
> >     like PEAK
> >     that use lazy importing to avoid slowing startup to a crawl (by
> >     deferring the
> >     actual import until the first time someone attempts to access the
> >     module's
> >     namespace).
> >
> > Fine with me.  It might change semantics in some odd way, though, so it
> > might be a Py3K change.
>
> I may have misunderstood what you meant by generalise...


I don't think you did.  There is a design choice of keeping highly common
things in __import__, or generalizing it out so that it uses the basic
infrastructure more.  This includes whether __import__ should handle
checking sys.modules itself or if that should be left to a meta_path
importer.

I think the only contention here is how to handle adding modules to
sys.modules during an import.  Someone has to stash something into
sys.modules to prevent recursion on a circular import dependency.  I had
suggested letting __import__ do it and to then just pass in the module to
load_module to remove that level of boilerplate.  Jim didn't like that since
it would restrict loaders to standard module objects because any other
import statements in a circular dependency would then store a reference to
the module.

My thing is that if they need something else they can swap out the module
first thing upon execution and use what they want.  It's a very small amount
of boilerplate, but I definitely could see myself forgetting to do it.

Either way, the key is that the module put into sys.modules cannot change
from when it's added and the module is initialized.  Otherwise circular
imports would end up with a different module than others who import later.

ah well, I'll wait
> and see what you come up with - I like what I've seen on this branch so
> far :)


Thanks!  Glad that my ideas have seemed sane to other people beyond just me.

The API redesign for the py/pyc handler is done and I am just finishing the
tests (I have 49 for the module so far).  Once the tests are finished I will
check it in.  I like the result because I abstracted the algorithm for
handling choosing bytecode over source, regenerating bytecode, etc., to a
point that opaque objects are used so that it is easy to use whatever setup
you want while not having to touch the basic algorithm.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-checkins/attachments/20061015/0d70d587/attachment.html