On 03/24/2018 09:27 AM, Rob Cliffe via Python-ideas wrote:
On 24/03/2018 14:44, Steven D'Aprano wrote:
On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote:
For PEP 572, the most directly comparable example is code like this:
# Any previous binding of "m" is lost completely on the next line m = re.match(...) if m: print(m.groups(0))
In order to re-use that snippet, you need to double-check the surrounding code and make sure that you're not overwriting an "m" variable already used somewhere else in the current scope.
Yes. So what? I'm going to be doing that regardless of whether the interpreter places this use of m in its own scope or not. The scope as seen by the interpreter is not important.
Good for you. But the proposed scoping rules are an extra safeguard for programmers who are less conscientious than you, or for anyone (including you) who is short of time, or misses something. An extra level of protection against introducing a bug is IMO a Good Thing.
But it's not a free thing. Our cars have seat belts, not six-point restraints, and either way the best practice is to be aware of one's surroundings, not rely on the safeguards to protect us against carelessness.
To the extent that this proposal to add sub-function scoping encourages people to do copy-paste coding without even renaming variables to something appropriate for the function they're pasted into, I think this will strongly hurts readability in the long run.
I think it will aid readability, precisely for the reason Nick gives: you need to make fewer checks whether variables are or are not used elsewhere.
Extra levels of intermingled scope are extra complication (for humans, too!); extra complication does not (usually) help readability -- I agree with D'Aprano that this is not a helpful complication.