[Python-Dev] PEP 382 progress: import hooks

[P.J. Eby]

At 05:28 PM 8/2/2010 -0700, Brett Cannon wrote:


>On Fri, Jul 23, 2010 at 09:54, P.J. Eby 
><<mailto:pje at telecommunity.com>pje at 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 at telecommunity.com>pje at 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.)