[Python-Dev] Fix import errors to have data (original) (raw)

Jim Fulton jim at zope.com
Mon Aug 2 16:01:28 CEST 2004

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

More information about the Python-Dev mailing list