[Python-Dev] Comment regarding PEP 328

[Josiah Carlson]

Guido van Rossum <gvanrossum at gmail.com> wrote:
> > 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.
> 
> Hm. I'm not convinced that there is a *problem* with shadowing of
> standard library module names. You shouldn't pick a module name that
> shadows a standard library module, or if you do you shouldn't want to
> be able to still use those modules that you're shadowing. Anything
> else is just asking for trouble.

While I personally don't tend to use names previously existing in
the standard library, seemingly a large number of people do, hence the
not-so-rare threads on comp.lang.python which ask about such things.


> > 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. **
> 
> And how exactly do you define "the standard library"? Anything that's
> on sys.path? That would seem the only reasonable interpretation to me.
> So I take it that you want the "script directory" off that path.
> (Let's for the sake of argument call it ".".)

Sounds reasonable to me, with one caveat; if one were to consider
everything on sys.path to be in the standard library, then every script
ever written for Python, which doesn't remove the standard ''/'.' from
sys.path, would be part of the standard library.

I would suggest, as a replacement definition (probably with a caveat or
two), that any module with a reference in the documentation, that also
lies on the default sys.path, which is shipped with Python that is
distributed at python.org, is part of the standard library.


> > The lack of a 'from __future__ import absolute_import' statement in a
> > module will not change the import semantic of that module.
> 
> It's hard to imagine how this would work. sys.path is global, so
> either "." is on it, or it isn't. So things in "." are either
> considered part of the standard library, or they are not; this can't
> be made dependent on the module's importation of something from
> __future__.

Perhaps not, but in the process of importing a module into a namespace,
one can check for the existance of the object imported from __future__,
and ignore or not the "." entry in sys.path.


> > 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.
> 
> My suggested way of dealing with their choices is summarized in the
> first paragraph of my reply above.

Perfectly reasonable.  I can think of examples where it would not be
reasonable, but they are quite cooked *wink*.


> > 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.
> 
> I don't like permanently optional language features; that causes too
> much confusion. I'd much rather settle on clear semantics that
> everyone can understand (even if they may disagree).
> 
> But I certainly would prefer that the proposed feature becomes a
> separate PEP which can be discussed, accepted or rejected, and
> implemented separately from PEP 328, which is complete and accepted
> and just awaiting someone to implement it.

Sounds good.  I'll see what I can do this weekend about getting a
proto-pep started.


> > 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.
> 
> But it's not always "" -- it's the directory where the "main" script was found.
> 
> Let me explain the biggest problem I see for your proposal: what would
> be the canonical name for a module imported using your "new relative
> semantics"? Remember, the canonical name of a module is its __name__
> attribute, and the key that finds it in the sys.modules dict. Because
> there's only one sys.modules dict (barring restricted execution
> sandboxes), the canonical name must be unique. So if there's a
> standard library module string, its canonical name is "string". Now
> suppose you have your own non-standard-linrary module read from a file
> string.py. What should its canonical name be? It can't be "string"
> because that's already reserved for the standard library module name.
> 
> The best solution I can think of for this off the top of my head is to
> somehow allow for the arrangement of a pseudo-package named __main__
> and to make all these non-standard-library modules reside (logically)
> in that module. If you can write a PEP along those lines you may be on
> to something -- but I expect that the way to turn it on is not to
> import something from __future__ but perhaps from __main__. I'm not
> exactly sure how to get "." off sys.path, but maybe you can think
> about that for your PEP proposal. What do you say?

You make very good points about naming in sys.modules.  I will think
about this and place some options in the proto-pep.

Thank you,
 - Josiah