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

[Brett Cannon]

On 10/12/06, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> On 10/11/06, brett.cannon <python-checkins at python.org> wrote:
> > New Revision: 52292
>
>
> ==============================================================================
> > --- sandbox/trunk/import_in_py/importer.py      (original)
> > +++ sandbox/trunk/import_in_py/importer.py      Thu Oct 12 01:56:56 2006
> > @@ -34,14 +34,18 @@
> >  Possible Py3K improvements:
> >      * Have __import__ check for sys.modules entry to alleviate need for
> every
> >        loader to do so.
> > -    * Have __import__ pass in module to initialize for imported module
> so to
> > -      alleviate loader from having to pull from sys.modules.
> > +    * Have __import__ pass into the loader the module to be initialized
> so as
> > +      remove that boilerplate (also keeps sys.modules manipulation
> within
> > +      __import__ when the previous suggestion is used).
>
> Putting a "just get the one that's already there" loader at the front
> should take care of this.


True.  It could just be a meta_path importer.

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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-checkins/attachments/20061012/c8faa888/attachment.htm