[Python-Dev] Re: Allow all assignment expressions after 'import something as'

[Guido van Rossum]

> On Mon, 21 Aug 2000, Guido van Rossum wrote:
> > > > > > Summary: Allow all assignment expressions after 'import
> > > > > > something as'
> [...]
> > I kind of doubt it, because it doesn't look useful.

[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.

> > I do want "import foo.bar as spam" back, assigning foo.bar to spam.
> 
> No no no no.  Or at least let's step back and look at the whole
> situation first.
> 
> "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.

>     (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.

>     (c) It's not clear whether this should work only for modules
>         named bar, or any symbol named bar.

Same as for import: bar must be a submodule (or subpackage) in package
foo.

> Before packages, the only two forms of the import statement were:
> 
>     import <module>
>     from <module> import <symbol>
> 
> After packages, the permitted forms are now:
> 
>     import <module>
>     import <package>
>     import <pkgpath>.<module>
>     import <pkgpath>.<package>
>     from <module> import <symbol>
>     from <package> import <module>
>     from <pkgpath>.<module> import <symbol>
>     from <pkgpath>.<package> import <module>

You're creating more cases than necessary to get a grip on this.  This
is enough, if you realize that a package is also a module and the
package path doesn't add any new cases:

  import <module>
  from <module> import <symbol>
  from <package> import <module>

> where a <pkgpath> is a dot-separated list of package names.
> 
> With "as" clauses, we could permit:
> 
>     import <module> as <localmodule>
>     import <package> as <localpackage>
> ??  import <pkgpath>.<module> as <localmodule>
> ??  import <pkgpath>.<package> as <localpackage>
> ??  import <module>.<symbol> as <localsymbol>
> ??  import <pkgpath>.<module>.<symbol> as <localsymbol>
>     from <module> import <symbol> as <localsymbol>
>     from <package> import <symbol> as <localsymbol>
>     from <pkgpath>.<module> import <symbol> as <localsymbol>
>     from <pkgpath>.<package> import <module> as <localmodule>

Let's simplify that to:

  import <module> as <localname>
  from <module> import <symbol> as <localname>
  from <package> import <module> as <localname>

> It's not clear that we should allow "as" on the forms marked with
> ??, since the other six clearly identify the thing being renamed
> and they do not.
> 
> Also note that all the other forms using "as" assign exactly one
> thing: the name after the "as".  Would the forms marked with ??
> assign just the name after the "as" (consistent with the other
> "as" forms), or also the top-level package name as well (consistent
> with the current behaviour of "import <pkgpath>.<module>")?
> 
> That is, would
> 
>     import foo.bar as spam
> 
> define just spam or both foo and spam?

Aargh!  Just spam, of course!

> All these questions make me uncertain...

Not me.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)