Nested scopes resolution -- you can breathe again!

[Russell Turpin]

Turpin:
>> And far from obscuring the intent, perhaps the SINGLE, 
>> BEST practice a programmer can employ, to help those 
>> who come later understand their work, is to put a 
>> manifest of all variables at the top of each function, 
>> class, and module.

Marcin 'Qrczak' Kowalczyk wrote:
> Not at all. You don't manifest names you refer to which 
> are defined at the module level, nor builtin names, nor 
> you don't explicitly state that they are local. Why would
> you make an exception for names bound in outer but not
> global scopes?

If you're using good programming practices, module names
either (a) explicitly refer to the module everywhere they
appear, e.g., "x = someMod.SomeClass()," or (b) are 
explicitly manifested where they are imported, e.g., 
"from someMod import SomeClass". The wildcard feature on 
the "from" statement is a mistake, and should be avoided. 
Using either (a) or (b), anyone reading the code can 
easily determine which variables are non-local, and where 
they originate.  

Built-in names are are simply part of the language. You
can't extrapolate from how they work to how names generally 
should work.

Even though Python doesn't implement data encapsulation,
it is good practice to lexically differentiate between 
private names and public ones. Where I work, we use naming 
conventions for this purpose. One of the problems with 
wildcard imports is the risk of accidental private name 
collision, where an imported module uses the same private
name as the one that imports it. 

Nested scoping essentially is a wildcard import from all 
containing scopes. There are a VERY FEW cases in OOP where 
this is genuinely useful. For the most part, its use 
should be avoided like the plague. 99% of the time it is
used, there is a more robust and more understandable way
to solve the problem without nested scoping. I understand
the desire for nested scoping with respect to lambda
definitions. Frankly, though, that seems a weak reason
for changing the name resolution mechanism. The only other
argument I've heard is that it makes Python more like
languages that borrowed naming rules from Algol. Python 
is a much better language than Algol, or most of its
successors, so I don't see why it should be jammed into 
that mold.

Python is a great language. Implicit declaration works 
well for programmers who have developed good programming
practices. It can be rope for those who haven't. The 
wildcard on import is a mistake. Someone should submit a
PEP to spit out a warning everytime someone uses it: 
"Hey STUPID! DON'T use wildcard on import!" Then, remove
it from Python3K.

Russell