[Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

[Glenn Linderman]

On 7/20/2011 4:03 PM, P.J. Eby wrote:
> I'd recommend *always* using it, outside of simple startup code.

So that is a burden on every program.  Documentation would help, but it 
certainly makes updating sys.path much more complex -- 3 lines (counting 
import of pkgutil) instead of one, and the complexity of understanding 
why there is a need for it, when in simple cases the single line works 
fine, but it would be bug prone to have both ways.


>
>> So I am still left with my original question:
>>
>>>> Is there some way to create a new __path__ that would reflect the 
>>>> fact that it has been dynamically created, rather than set from 
>>>> __init__.py, and then when it is referenced, calculate (and cache?) 
>>>> a new value of __path__ to actually search?
>
> Hm.  Yes, there is a way to do something like that, but it would 
> complicate things a bit

 From what you said, it would complicate the solution for complex 
packaging tasks, but would return simple extensions of sys.path to being 
simple again.  Sounds like a good tradeoff, but I'll leave that to you 
and other more knowledgeable people to figure out the details and 
implementation... I snipped the explanation, because it is beyond my 
present knowledge base.

> Anyway, it seems worth considering.  We just need to sort out what the 
> downsides are for any current tools thinking that such modules aren't 
> packages.  (But hey, at least it'll be consistent with what such tools 
> would think of the on-disk representation!  That is, a tool that 
> thinks foo.py alongside a foo/ subdirectory is just a module with no 
> package, will also think that 'foo', once imported, is a module with 
> no package.)

Please consider it.  I think your initial proposal solves some problems, 
but a version that doesn't complicate the normal, simple, extension of 
sys.path would be a much better solution, so I am happy to hear that you 
have ideas in that regard.  Hopefully, they don't complicate things too 
much more.  So far, I haven't gotten my head around packages as they 
presently exist (this __init__.py stuff seems much more complex than the 
simplicity of Perl imports that I was used to, although I certainly like 
many things about Python better than Perl, and have switched 
whole-heartedly, although I  still have a fair bit of Perl code to port 
in the fullness of time).  I think your proposal here, although 
maintaining some amount of backward-compatibility may require complexity 
of implementation, can simplify the requirements for creating new 
packages, to the extent I understand it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110720/d28ac334/attachment.html>