Although David has already copy-posted a message regarding this issue
to the list, I would like to restate the problem to get a discussion
going (and then maybe take it to c.l.p for general flaming ;).
The problem we have run into on starship is that some well-known
packages have introduced naming conflicts leading to the unfortunate
situation that they can't be all installed on the same default
path:
1. Zope has a module named DateTime which also is the base name of the
package mxDateTime.
2. Both Zope and PIL have a top-level module named ImageFile.py
(different ones of course).
Now the problem is how to resolve these issues. One possibility
is turning Zope and PIL into proper packages altogether. To
ease this transition, one would need a way to specify relative
intra-package imports and a way to tell pickle where to look
for modules/packages.
The next problem we'd probably run into sooner or later is that
there are quite a few useful top-level modules with generic
names that will conflict with package names and other modules
with the same name.
I guess we'd need at least three things to overcome this situation once
and for all ;-):
1. Provide a way to do relative imports, e.g. a single dot could
be interpreted as "parent package":
modA.py
modD.py
[A]
modA.py
modB.py
[B]
modC.py
modD.py
In modC.py:
from modD import * (works as usual: import A.B.modD)
from .modA import * (imports A.modA)
from ..modA import * (import the top-level modA)
2. Establish a general vendor based naming scheme much like the one
used in the Java world:
from org.python.core import time,os,string
from org.zope.core import *
from com.lemburg import DateTime
from com.pythonware import PIL
3. Add a way to prevent double imports of the same file.
This is the mayor gripe I have with pickle currently, because intra-
package imports often lead to package modules being imported
twice leading to many strange problems (e.g. splitting class
hierarchies, problems with isinstance() and issubclass(), etc.), e.g.
from org.python.core import UserDict
u = UserDict.UserDict()
import UserDict
v = UserDict.UserDict()
Now u and v will point to two different classes:
>>> u.__class__
<class org.python.core.UserDict.UserDict at 80d3b48>
>>> v.__class__
<class UserDict.UserDict at 80aed18>
4. Add some kind of redirection or lookup hook to pickle et al.
so that imports done during unpickling can be redirected to the
correct (possibly renamed) package.
--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: 196 days left
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
to the list, I would like to restate the problem to get a discussion
going (and then maybe take it to c.l.p for general flaming ;).
The problem we have run into on starship is that some well-known
packages have introduced naming conflicts leading to the unfortunate
situation that they can't be all installed on the same default
path:
1. Zope has a module named DateTime which also is the base name of the
package mxDateTime.
2. Both Zope and PIL have a top-level module named ImageFile.py
(different ones of course).
Now the problem is how to resolve these issues. One possibility
is turning Zope and PIL into proper packages altogether. To
ease this transition, one would need a way to specify relative
intra-package imports and a way to tell pickle where to look
for modules/packages.
The next problem we'd probably run into sooner or later is that
there are quite a few useful top-level modules with generic
names that will conflict with package names and other modules
with the same name.
I guess we'd need at least three things to overcome this situation once
and for all ;-):
1. Provide a way to do relative imports, e.g. a single dot could
be interpreted as "parent package":
modA.py
modD.py
[A]
modA.py
modB.py
[B]
modC.py
modD.py
In modC.py:
from modD import * (works as usual: import A.B.modD)
from .modA import * (imports A.modA)
from ..modA import * (import the top-level modA)
2. Establish a general vendor based naming scheme much like the one
used in the Java world:
from org.python.core import time,os,string
from org.zope.core import *
from com.lemburg import DateTime
from com.pythonware import PIL
3. Add a way to prevent double imports of the same file.
This is the mayor gripe I have with pickle currently, because intra-
package imports often lead to package modules being imported
twice leading to many strange problems (e.g. splitting class
hierarchies, problems with isinstance() and issubclass(), etc.), e.g.
from org.python.core import UserDict
u = UserDict.UserDict()
import UserDict
v = UserDict.UserDict()
Now u and v will point to two different classes:
>>> u.__class__
<class org.python.core.UserDict.UserDict at 80d3b48>
>>> v.__class__
<class UserDict.UserDict at 80aed18>
4. Add some kind of redirection or lookup hook to pickle et al.
so that imports done during unpickling can be redirected to the
correct (possibly renamed) package.
--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: 196 days left
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/