At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:
On Thu, Jul 22, 2010 at 19:19, P.J. Eby <mailto:email@example.com@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?
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...?
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.