[Python-Dev] Fix import errors to have data

[Jim Fulton]

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