nested scopes

[Robin Becker]

In article <mailman.981139624.1198.python-list at python.org>, Thomas
Wouters <thomas at xs4all.net> writes
.....
>Now, now, 'hacked' is a bit strong. Jeremy did a fairly extensive rewrite of
>the compiler, complete and decent enough not to be called a 'hack' for sure.
>Besides, developers never 'hack', they 'extend' :-) The problem with 'from
>foo import *' in a function or class scope, though, is that it makes it
>impossible for the compiler to see what names will be defined in that scope,
>and hence what names a nested scope uses will resolve to that. I don't like
>it at all, either. In fact, I was the first to whine about it, incessantly,
>on python-dev. I think I have to buy Jeremy a beer (or whatever's his
>poison) on the Python conference to make up ;)
>

I really don't understand why this short cut should be considered such
an abomination. Not using it leads to bad maintenance problems ie I
either flood my module with names by importing right at the top or I am
forced to explicitly import in the target scope. Any name changes in the
origin module must then be pursued over the whole world.

As for the compiler statically determining what's in scope I thought the
whole point of python was that it was dynamic and did late binding.

I can't figure out how any compiler is going to figure out

that

def outer(name):
 exec name + '=1'
 def inner():
  return g
 return inner()

can work if I call outer('g') so this must only be static scoping; if
it's static why should dynamic events like imports be clashing with it.
I suppose there's some attempt at code optimisation being pursued. 

Optimality is the enemy of stability. 
-- 
Robin Becker