[Python-Dev] Don't assign to a variable used later in the expression

[Ivan Pozdeev]

On 05.07.2018 3:40, Ivan Pozdeev via Python-Dev wrote:
> On 05.07.2018 2:29, Nathaniel Smith wrote:
>> On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
>> <python-dev at python.org>  wrote:
>>> On 04.07.2018 10:10, Nathaniel Smith wrote:
>>>> Right, Python has a *very strong* convention that each line should
>>>> have at most one side-effect, and that if it does have a side-effect
>>>> it should be at the outermost level.
>>>> I think the most striking evidence for this is that during the
>>>> discussion of PEP 572 we discovered that literally none of us –
>>>> including Guido – even *know* what the order-of-evaluation is inside
>>>> expressions. In fact PEP 572 now has a whole section talking about the
>>>> oddities that have turned up here so far, and how to fix them. Which
>>>> just goes to show that even its proponents don't actually think that
>>>> anyone uses side-effects inside expressions, because if they did, then
>>>> they'd consider these changes to be compatibility-breaking changes. Of
>>>> course the whole point of PEP 572 is to encourage people to embed
>>>> side-effects inside expressions, so I hope they've caught all the
>>>> weird cases, because even if we can still change them now we won't be
>>>> able to after PEP 572 is implemented.
>>> I may have a fix to this:
>>>
>>> Do not recommend assigning to the variable that is used later in the
>>> expression.
>> This would rule out all the comprehension use cases.
> Only those outside of the outermost iterable.
Scratch this line, it was from an earlier edit of the letter. I 
invalidate this myself further on.
>> I'd be fine with that personally. Reading through the PEP again I see
>> that there are more examples of them than I previously realized,
>> inside the semantics discussion and... well, this may be a personal
>> thing but for me they'd all be better described as "incomprehensions".
>> But, nonetheless, the comprehension use cases are supposed to be a
>> core motivation for the whole PEP.
>
> Far from it. If/while, too. Any construct that accepts an expression 
> and uses its result but doesn't allow to insert an additional line in 
> the middle qualifies.
>> Also, some of the main arguments
>> for why a full-fledged := is better than the more limited alternative
>> proposals rely on using a variable on the same line where it's
>> assigned (e.g. Tim's gcd example). So I don't see this recommendation
>> getting any official traction within PEP 572 or PEP 8.
> That's actually a valid use case!
> In the aforementioned example,
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>      return g
>  the variable `diff' doesn't exist before, so there's no confusion 
> which value is used.
>
>
> Okay, I stay corrected:
>
> _Do not recommend *changing* a variable that is used later in the 
> expression._
>
> I.e. the variable should not exist before assignment (or effectively 
> not exist -- i.e. the old value should not be used).
>
>
> E.g., good:
>
>     [ rem for x in range(10) if rem := x%5 ]
>
> bad:
>
>     [ sum_ for x in range(10) if (sum_ := sum_ + x) % 5 ]     # good 
> luck figuring out what sum_ will hold
>
>
>> Of course you're free to use whatever style rules you prefer locally –
>> python-dev has nothing to do with that.
>>
>> -n
>>
>
> -- 
> Regards,
> Ivan
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru

-- 
Regards,
Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/fb09395f/attachment.html>