At 08:28 AM 7/30/04 -0400, Jim Fulton wrote: >The problem with Python's current package system is that it's not possible, >in general, to write packages that can be moved around within the package >system, because relative imports aren't reobust or flexible enough. >PEP 328 would fix this. PEP 328 would allow creation of packages that >worked regardless of where there were places or that worked relative >to a containing package regardless of where that was placed. You could >then have different module spaces expressed by adding a new layer of top-level >modules. You wouldn't need any new machinery beyond PEP 328. Hm. The concept I'm proposing would allow code to be used in a module space without needing to know about module spaces or be written to co-operate in such a fashion. If you can make everybody conform to some sort of coding standard, you wouldn't even need PEP 328 to accomplish your goal. ;) As a counterexample, consider seven Zope products that depend on two different versions of PIL. Using PEP 328, you can't make this work without either loading seven copies of PIL, or else requiring the version number to be part of the package name. You actually have it somewhat better right now because you can at least fool the "this package or absolute" mechanism into doing what you want. If I understand correctly, PEP 328 will ultimately remove the possibility of doing it that way.
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