[stdlib-sig] the "py" prefix
mal at egenix.com
Fri Apr 11 22:01:03 CEST 2008
On 2008-04-11 20:41, Brett Cannon wrote:
> On Fri, Apr 11, 2008 at 9:50 AM, Antoine Pitrou <solipsis at 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.
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.
Professional Python Services directly from the Source (#1, Apr 11 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the stdlib-sig