[Python-Dev] Fix import errors to have data
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