On Fri, Jul 23, 2010 at 09:54, P.J. Eby <p...@telecommunity.com> wrote:
> At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote: > > > > On Thu, Jul 22, 2010 at 19:19, P.J. Eby <<mailto:p...@telecommunity.com> >> p...@telecommunity.com> wrote: >> >> What does "is not a package" actually mean in that context? >> >> >> The module is a module but not a package. >> > > Um... that's not any clearer. Are you saying that a module of the same > name takes precedence over a package? Is that the current precedence as > well? > No, packages take precedence. I meant that something is a module but it is not a package; a package implicitly includes a module, but a module is not automatically a package. > > > Regarding load_module_with_path(), how does its specification differ from >> simply creating a module in sys.modules, setting its __path__, and then >> invoking the standard load_module()? Ā (i.e., is this method actually >> needed, since a correct PEP 302 loader *must* reuse an existing module >> object in sys.modules) >> >> >> It must reuse the module itself but a proper reload would reset __path__ >> as leaving it unchanged is not a proper resetting of the module object. So >> this module is needed in order to force the loader >> > > Um, no. Reloading doesn't reset the module contents, not even __path__. > Never has, from Python 2.2 through 2.7 -- even in 3.1. At least, not for > normal filesystem .py/.pyc files. (I tested with 'os', adding an extra > 'foo' attribute, and also setting a __path__; both were unaffected by > reload(), in all 7 Python versions. > > Perhaps you're saying this happens with zipfiles, or packages that already > have a __path__, or...? > It's how I implemented it in importlib and it passes Python's unit test suite that way; zipimport also does it this way as it too does not differentiate a reload from a clean load beyond grabbing the module from sys.modules if it is already there. PEP 302 does not directly state that reloading should not reset the attributes that import must set, simply that a module from sys.modules must be reused. Since zipimport does it this way I wouldn't count on other loaders not setting __path__. > > > >> >> Am I correct in understanding that, as written, one would have to redefine >> __import__ to implement this in a library for older Python versions? Ā Or is >> it implementable as a meta_path importer? >> >> >> >> Redefine __import__ (unless Martin and I are missing something, but I >> tried to think of how to implement this use sys.meta_path and couldn't come >> up with a solution). >> > > I'm thinking it *could* be done with a meta_path hook, but only by doubling > the search length in the event that the search failed. That seems a bit > icky, but replacing the entire import process seems ickier (more code > surface to maintain, more bug potential) in the case of supporting older > Pythons. > > I'm personally not worried about supporting older versions of Python as this is a new feature. Better to design it properly than come up with some hack solution as we will all have to live with this for a long time.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
