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