[Python-Dev] Is outlawing-nested-import-* only an implementation issue?

[Ka-Ping Yee]

On Thu, 22 Feb 2001, Guido van Rossum wrote:

> >     1.  "exec('x = 1')" should behave exactly the same as "x = 1"
> 
> Sorry, no go.  This just isn't a useful feature.

It's not a "feature" as in "something to be added to the language".
It's a consistent definition of "exec" that simplifies understanding.

Without it, how do you explain what "exec" does?

> >     2.  "from foo import *" should do the same as "x = 1"
> 
> But it is limiting because it hides information from the compiler, and
> hence it is outlawed when it gets in the way of the compiler.

Again, consistency simplifies understanding.  What it "gets in the
way of" is a particular optimization; it doesn't make compilation
impossible.

The language reference says that import binds a name in the local
namespace.  That means "import x" has to do the same thing as "x = 1"
for some value of 1.  "from foo import *" binds several names in the
local scope, and so if x is bound in module foo, it should do the
same thing as "x = 1" for some value of 1.

When "from foo import *" makes it impossible to know at compile-time
what bindings will be added to the current scope, we just do normal
name lookup for that scope.  No big deal.  It already works that way
at module scope; why should this be any different?

With this simplification, there can be a single scope chain:

    builtins <- module <- function <- nested-function <- ...

and all scopes can be treated the same.  The implementation could
probably be both simpler and faster!  Simpler, because we don't
have to have separate cases for builtins, local, and global; and
faster, because some of the optimizations we currently do for
locals could be made to apply at all levels.  Imagine "fast globals"!
And imagine getting them essentially for free.

> >     3.  "def g(): print x" should behave the same as "print x"
> 
> Huh? again.  Defining a function does't call it.

Duh, obviously i meant

    3.  "def g(): print x" immediately followed by "g()" should
        behave the same as "print x"

Do you agree with this principle, at least?

> Python has always
> adhered to the principle that the context where a function is defined
> determines its context, not where it is called.

Absolutely agreed.  I've never intended to contradict this.  This
is the foundation of lexical scoping.


-- ?!ng

"Don't worry about people stealing an idea.  If it's original, you'll
have to jam it down their throats."
    -- Howard Aiken