[Python-Dev] Re: Allow all assignment expressions after 'import something as' (original) (raw)
Ka-Ping Yee ping@lfw.org
Thu, 24 Aug 2000 04:14:12 -0500 (CDT)
- Previous message: [Python-Dev] Re: Allow all assignment expressions after 'import something as'
- Next message: [Python-Dev] Re: Allow all assignment expressions after 'import something as'
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 23 Aug 2000, Guido van Rossum wrote:
[Ping] > Looks potentially useful to me. If nothing else, it's certainly > easier to explain than any other behaviour i could think of, since > assignment is already well-understood.
KISS suggests not to add it. We had a brief discussion about this at our 2.0 planning meeting and nobody there thought it would be worth it, and several of us felt it would be asking for trouble.
What i'm trying to say is that it's easier to explain "import as" with Thomas' enhancement than without it.
The current explanation of "import as " is something like
Find and import the module named <x> and assign it to <y>
in the normal way you do assignment, except <y> has to be
a pure name.
Thomas' suggestion lifts the restriction and makes the explanation simpler than it would have been:
Find and import the module named <x> and assign it to <y>
in the normal way you do assignment.
"The normal way you do assignment" is shorthand for "decide whether to assign to the local or global namespace depending on whether has been assigned to in the current scope, unless has been declared global with a 'global' statement" -- and that applies in any case. Luckily, it's a concept that has been explained before and which Python programmers already need to understand anyway.
The net effect is essentially a direct translation to
<y> = __import__("<x>")
> "import foo.bar as spam" makes me uncomfortable because: > > (a) It's not clear whether spam should get foo or foo.bar, as > evidenced by the discussion between Gordon and Thomas.
As far as I recall that conversation, it's just that Thomas (more or less accidentally) implemented what was easiest from the implementation's point of view without thinking about what it should mean. Of course it should mean what I said if it's allowed. Even Thomas agrees to that now.
Careful:
import foo.bar "import the package named foo and its submodule bar,
then put *foo* into the current namespace"
import foo.bar as spam "import the package named foo and its submodule bar,
then put *bar* into the current namespace, as spam"
Only this case causes import to import a different object just because you used "as".
import foo "import the module named foo, then put foo into
the current namespace"
import foo as spam "import the module named foo, then put foo into
the current namespace, as spam"
The above, and all the other forms of "import ... as", put the same object into the current namespace as they would have done, without the "as" clause.
> (b) There's a straightforward and unambiguous way to express > this already: "from foo import bar as spam".
Without syntax coloring that looks word soup to me. import foo.bar as spam uses fewer words to say the same clearer.
But then:
from foo import bar as spam # give me bar, but name it spam
import foo.bar as spam # give me bar, but name it spam
are two ways to say the same thing -- but only if bar is a module. If bar happens to be some other kind of symbol, the first works but the second doesn't!
Not so without "as spam":
from foo import bar # give me bar
import foo.bar # give me foo
> That is, would > > import foo.bar as spam > > define just spam or both foo and spam?
Aargh! Just spam, of course!
I apologize if this is annoying you. I hope you see the inconsistency that i'm trying to point out, though. If you see it and decide that it's okay to live with the inconsistency, that's okay with me.
-- ?!ng
- Previous message: [Python-Dev] Re: Allow all assignment expressions after 'import something as'
- Next message: [Python-Dev] Re: Allow all assignment expressions after 'import something as'
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]