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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4