At 05:28 PM 8/2/2010 -0700, Brett Cannon wrote:
On Fri, Jul 23, 2010 at 09:54, P.J. Eby <mailto:pje@telecommunity.compje@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:pje@telecommunity.compje@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.)