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?
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.
_______________________________________________
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
