On 2008-04-11 20:41, Brett Cannon wrote:
On Fri, Apr 11, 2008 at 9:50 AM, Antoine Pitrou solipsis@pitrou.net wrote:
With the stricter distinction between absolute and relative imports, isn't all this discussion a bit obsolete ?
If you want to import the builtin "types" module: import types If you want to import the local "types" module: from . import types
I don't see the need for a "py" prefix.
But what if you want to install a third-party library that is named 'types'? ``import types`` will import either from the stdlib or the third-party library based on sys.path. The thinking for the top-level 'py' namespace is that this situation becomes (basically) impossible.
Exactly.
The problem is not related to relative vs. absolute imports, it's all about sys.path.
Detecting such situations gets even harder once you start to use eggs, since they hide away the module names they use insider their ZIP archives.
Also note that this is not so much a problem for the existing set of std lib modules since 3rd party packages will of course try to not conflict with these known names.
However, it becomes an issue as soon as new modules get added to the std lib or existing ones are renamed.
In such a situation, you have the case that a conflicting module will already be in use (possibly buried inside some egg on sys.path) and changing all the code that relies on this conflicting module will not necessarily be easy.
The "py." prefix would solve these issues once and for all.
Note that these situations are not made up. You can run into such situations quite easily, e.g. if you run python in a directory that happens to have a package called "test" with an __init__.py in it, you suddenly cannot access the Python stdlib test package anymore.