Phillip J. Eby wrote: > 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. ;) I don't think that's true. If your package has sub-packages, there's no way for a subackage to import from the containing package without using an absolute import. Similarly, a package currentlly can't import from a sibling package without using an absolute import. With PEP 328, relative imports from parent or sibling (or cousin ...) packages will be possible. > > 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. No, I don't think this is right. PEP 328 should allow you to create module spaces using container packages. For your example, we create two top-level packages, space1 and space 2. You put version x of PIL in space1. That package's absolute name is space1.PIL. You put version y of PIL in space2, creating space2.PIL. Now you put the products that depend on version x of PIL in space1. You put the products that depend on version y of PIL on space 2. The products mist use relative imports to import from PIL: from ..PIL import somePILmodule For this to work, PIL also has to use relative imports to import it's own modules. > 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. I assume you are fering to letting local modules hide global ones. This only works if the modules are included directly in the package. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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