At 05:28 PM 8/2/2010 -0700, Brett Cannon wrote:
On Fri, Jul 23, 2010 at 09:54, P.J. Eby
<<mailto:p...@telecommunity.com>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.
That explanation still isn't making things any clearer for me. That
is, I don't know how to get from that statement to actual code, even
if I were writing a filesystem or zip importer, let alone anything more exotic.
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__.
Fair enough, though certainly unfortunate. In particular, it means
that it's not actually possible to correctly/completely implement PEP
382 on any already-released version of Python, without essentially
replacing zipimport. (Unless the spec can be tweaked a bit.)
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.
Currently, older Pythons are the only versions I *do* support, so I'm
very concerned with it. Otherwise, I'd not be asking all these questions. ;-)
Personally, I think there are features in the PEP that make things
unnecessarily complicated - for example, supporting both __init__.py
*and* .pth files in the same directory. If it were either/or, it
would be a LOT easier to implement on older Pythons, since it
wouldn't matter when you initialized the __path__ in that case.
(By the way, there were some other questions I asked about the PEP
382 revisions, that you didn't reply to in previous emails (such as
the format of the strings to be returned by find_path()); I hope
either you or Martin can fill those in for me, and hopefully update
the PEP with the things we have talked about in this thread.)
_______________________________________________
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
