Statement local namespaces - a different perspective
Last night, I realized something interesting about statement local namespaces:
Pretty much all the arguments, both for and against, apply to allowing suites in compound statements.
I take it as given that any suite in a statement can be refactored into a function definition and an appropriate invocation of that function, even though it may require returning a tuple into a tuple assignment. This is one of the key features of programming languages in general.
So we could, in theory, restrict all compound statements suites to a single statement. If you needed more than one statement in them, you'd have to wrap the suite in a named function and invoke it appropriately.
The benefits from this restriction would be the same as they are for disallowing statement-local namespaces: it makes the suite available for independent testing and reuse, forces the programmer to come up with a (hopefully) descriptive name, and forces parts to be defined before they are used. The downsides are the same problems that the statement-local namespace proposals are addressing: having to come up with a good name, polluting the namespace, and giving the parts more prominent placement than the whole.
Python doesn't do this for compound statements because it's impractical. Not every arbitrary collection of statements that needs to be grouped in a suite has a descriptive name or needs to be reused. Putting them in a named function just means you should test the function as well as the statement. In such cases, it's better to just embed the suite into the statement, and Python allows that.
I believe the same thing applies to values in an expression. Not every group of sub-expressions has a good name or needs to be reused. Putting them in a named function just means you should test the function as well as the statement. In such cases, the code would be better if you could just embed the suite into the statement. I think it's time Python allowed that.