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

[Ivan Pozdeev]

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.
> 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

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