[Python-Dev] Comment regarding PEP 328

[Josiah Carlson]

In a recent discussion in a SF patch, I noticed that PEP 328* only seems
to support relative imports within packages, while bare import
statements use the entirety of sys.path, not solving the shadowing of
standard library module names.

I have certainly forgotten bits of discussion from last spring, but I
would offer that Python could offer standard library shadowing
protection through the use of an extended PEP 328 semantic.

More specifically; after a 'from __future__ import absolute_import'
statement, any import in the module performing "import foo" will only
check for foo in the standard library, and the use of the leading period,
"from . import foo", the will signify relative to the current path. **

The lack of a 'from __future__ import absolute_import' statement in a
module will not change the import semantic of that module.


This allows current code to continue to work, and for those who want to
choose names which shadow the standard library modules, a way of dealing
with their choices.

Further, in the case of PEP 328, the package relative imports were to
become the default in 2.6 (with deprecation in 2.5, availability in 2.4),
but with the lack of an implementation, perhaps those numbers should be
incremented.  If the behavior I describe is desireable, it would subsume
PEP 328, and perhaps should also become the default behavior at some
point in time (perhaps in the same adjusted timeline as PEP 328).

Alternatively, PEP 328 could be implemented as-is, and a second future
import could be defined which offers this functionality, being
permanently optional (or on a different timeline) via the future import.

Essentially, it would ignore the empty path "" in sys.path when the
functionality has been enabled via the proper future import in the
current module.


 - Josiah


* PEP 328 first describes the use of parenthesis in import statements so
that long import listings do not require backslash-escaping of newlines. 
It then describes a semantic for not checking sys.path when performing
an import, as well as allowing parent, cousin, uncle, etc., imports via
additional leading periods.  "from . import foo" for sibling imports,
"from .. import foo" for parent imports, etc.

** I describe the semantic as being a per-module option, as this is the
only backwards-compatible mechanism in the near future (Python 2.5). An
import implementation would merely check the existance of the proper
name binding -> object pair in the importer's global namespace.  The
standard library would need to be modified if or when current behavior
is deprecated (this would extend the modules needing to be modified due
to PEP 328).