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.
Sure. There are lots of FAQs whose answer is not "Python will have to change".
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.
This is not an operational definition for the sake of what you're trying to accomplish; the import statement cannot possibly know which modules are considered standard according to this definition.
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.
How would you recognize the "." entry in sys.path? (Remember "." is just the name we give it, not its actual value.) It is not a fixed string; it is not in a fixed position; it may even have been added explicitly to sys.path in which case it should act as if its contents was part of the standard library.
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*.
OK, then let's drop the issue -- my initial point was "this is not broken so there's no need to fix it."
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.
You make very good points about naming in sys.modules. I will think about this and place some options in the proto-pep.
I recommend that you try to produce a working implementation (using import hooks so you can write the whole thing in Python). This is likely to clarify many of the semantic problems that I have tried to hint at.