(Serious?) package namespace problem (and a proposal)

Huaiyu Zhu hzhu at knowledgetrack.com
Wed Jun 28 16:25:23 EDT 2000


Given the following directory structure,

python/
   AAA.py
   BBB/
      __init__.py
      AAA.py
      
if sys.path contains 'python', then 

from AAA import *
from BBB.AAA import * 

would do the right thing at most locations, except when pwd is python/ and
when '.' is before 'python' in sys.path, in which case they both import from
python/AAA.py.

Is this a fair description of current situation?  If so this makes package
name spaces essentially flat. That is, in order to avoid name clashes one
has to avoid identical module names even if they are buried deep inside
packages.  This is even worse on Windows - its file names are caseless - as
one has to avoid filenames with different cases as well.

This situation occurs quite often in practice.  For example, AAA could be a
module for doing something.  BBB could be a wrapper package for doing things
somewhat differently.  So within BBB/AAA.py one calls 'import AAA' to get
the real job done, and oops, it imports itself!

Although it is not advisable to put '.' in path, especially at front, a lot
of people actually do. And the functionality of a package should not depend
on this detail.  Otherwise what happens if one imports several packages each
expecting a different ordering of sys.path?

In Unix shells, however, this can always be overcome by using absolute
paths, like /the/absolute/path/command, whatever the PATH is.

So now to my proposed solution.  Is it possible to have something like this?

sys.rootpath  = ['/usr/lib/python1.5', '/usr/lib/python1.5/site-packages']
from rootpath.AAA import *
from rootpath.BBB.AAA.import *

This guarantees that module names within packages are well separated.  One
can still use 
from AAA import *
to import from any module named AAA that happens to be in the path. IMHO,
this would not break any existing code (unless it happens to contain the new
keyword 'rootpath').  It would certainly facilitate much easier use of
packages. The only real problem I can see of is that developers might (for
what reason?) rush to occupy real estates under rootpath.  But since the
standard distribution is centrally controlled and add-ons are user
controlled, this shouldn't be a big problem.



-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net 



More information about the Python-list mailing list