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

[Huaiyu Zhu]

To summarize the thread I started:

1. The problem was caused by
 (1) relative import (or, rather, lacking support for global import)
 (2) Windows case insensitivity (only incidentally)
 (3) having a module name that is identical to global package name
 
   It is not caused by
 (1) having a '.' in sys.path
 (2) using import *

Thanks to Gordon McMillan for the clear explanation.

2. The immediate solution is to rename all module names to avoid global
package or module names.  This is not a long term solution for Python [1].

3. Another solution is to use the imputils module.  The docs take quite some
time to read.

4. The long term solution is to introduce a syntax for specifying global
imports.  Proposals include:

import .AAA
import magicroot.AAA  # magicroot in ["rootpath", "pythonroot", "python"]
import global AAA
global import AAA
import global.AAA
from global import AAA

The first is not explicit enough.  The second introduces a new keyword
unnecessarily.  The third introduces a new syntax.  The last three look
promising.  The last two fit completely within current syntax and will not
change the default behavior in any working code.

[Another proposal is to require relative imports to use 'import .AAA' but
that breaks most of existing code.]

5. There is one issue I mentioned that has not been followed up: The global
package name space cannot be the same as sys.path as it could contain '.' or
anything else.  It seems one additional attribute in sys is necessary:

sys.globalpath = ["/usr/lib/python1.5", "/usr/lib/python1.5/site-packages"]

Once these proposals are implemented, Python's module namespace would be
well encapsulated: Only top level package names need to be distinguished.
The module names within a package will not be affected by any name outside
the package.


-----------------
[1] Problems with avoiding using identical names:

Problem 1.  With this advice one has to avoid any existing or future global
package or module names that _might_ need to be imported in later
implementations.  Once a package gets widely used its module names cannot be
easily changed.  New package names also need to avoid using names of any
modules inside any existing or future packages.  For windows compatibility
"identical" is also case insensitive.

Such restrictions are simply too severe and unwarrantied.  And they go
against the elegance of Python exhibited in other aspects.  It is not
necessary to prefix variable names with indicators of their project names
because module name spaces provide good protection.  It would be a tragedy
(what else can I say) that one has to prefix module names with package
indicators because packages do not provide similar protection.

Problem 2. This is unlike variable names where: (1) there is a global
keyword, (2) global variables can still be qualified by module names.  In
contrast blocked package names are simply inaccessible, even if one is
willing to use a keyword or qualifier.

Huaiyu