On Fri, Jul 23, 2010 at 09:54, P.J. Eby
<pje@telecommunity.com> wrote:
At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:
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.