[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:
> >     Having __import__ always generate the module would make it harder to
> >     use things that aren't really modules.  (examples:  A module with a
> >     custom __dict__ type that gripes at external modification; the
> >     forwarders used when a module changes its name; Lazy Importers)
> >
> >
> > Good point.  Question is whether these use-cases will occur enough to
> > make it worth it.  We can either lean towards hyper-generalization or
> > try to minimize what the importer/loaders have to do.
>
> 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.

The minimisation of what importers/loaders have to do can be handled the
> same
> you're handling it for your code - by providing pluggable base classes
> that
> delegate to internal methods.


Yeah.  I really want to keep the interfaces simple and minimize the amount
of repeated code.  But I also want to be flexible enough so that people can
reuse common things (e.g., the filesystem importer/loaders) easily.

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