[Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Guido van Rossum guido at python.org
Tue Mar 27 22:15:40 EDT 2018


This thread is dead.

On Tue, Mar 27, 2018 at 5:40 PM, Rob Cliffe via Python-ideas <
python-ideas at python.org> wrote:

>
>
> On 28/03/2018 01:19, Steven D'Aprano wrote:
>
>> On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas
>> wrote:
>>
>>> On 27/03/2018 16:22, Guido van Rossum wrote:
>>>
>>>> The standard reply here is that if you can't tell at a glance whether
>>>> that's the case, your code is too complex. The Zen of Python says
>>>> "Namespaces are one honking great idea -- let's do more of those!" and
>>>> in this case that means refactor into smaller namespaces, i.e.
>>>> functions/methods.
>>>>
>>>> This is not always satisfactory.  If your for-loop uses 20
>>> already-defined-locals, do you want to refactor it into a function with
>>> 20 parameters?
>>>
>> The standard reply here is that if your for-loop needs 20 locals, your
>> function is horribly over-complex and you may need to rethink your
>> design.
>>
>> And if you don't think "20 locals" is too many, okay, how about 50? 100?
>> 1000? At some point we'll all agree that the function is too complex.
>>
>> We don't have an obligation to solve every problem of excess complexity,
>> especially when the nominal solution involves adding complexity
>> elsewhere.
>>
>> For 25 years, the solution to complex functions in Python has been to
>> refactor or simplify them. That strategy has worked well in practice,
>> not withstanding your hypothetical function.
>>
>> If you genuinely do have a function that is so highly coupled with so
>> many locals that it is hard to refactor, then you have my sympathy but
>> we have no obligation to add a band-aid for it to the language.
>>
> It's a fact of life that some tasks *are* complicated.  I daresay most
> aren't, or don't need to be, but some are.
>
>>
>> Putting the loop variable in its own scope doesn't do anything about the
>> real problem: you have a loop that needs to work with twenty other local
>> variables. Any other modification to the loop will run into the same
>> problem: you have to check the rest of the function to ensure you're not
>> clobbering one of the twenty other variables. Special-casing the loop
>> variable seems hardly justified.
>>
>> If there is a justification for introducing sub-local scoping, then I
>> think it needs to be something better than pathologically over-complex
>> functions.
>>
>>
>> But putting the loop variable in its own scope solves one problem: it
> ensures that the variable is confined to that loop, and you don't have to
> worry about whether a variable of the same name occurs elsewhere in your
> function.  In other words it increases local transparency (I'm not sure
> that's the right phrase, but I'm struggling to bring a more appropriate one
> to mind) and hence increases readability.
> (I understand your point about being able to inspect the for-loop variable
> after the for-loop has terminated - I've probably done it myself - but it's
> a matter of opinion whether that convenience outweighs the cleanliness of
> confining the for-variable's scope.)
> Regards
> Rob Cliffe
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180327/f8194055/attachment.html>


More information about the Python-ideas mailing list