[Python-Dev] Examples for PEP 572

Ivan Pozdeev vano at mail.mipt.ru
Wed Jul 4 13:33:17 EDT 2018

On 04.07.2018 11:54, Serhiy Storchaka wrote:
> 04.07.18 10:06, Tim Peters пише:
>> [Tim]
>>  >> I really don't know what Guido likes best about this, but for me 
>> it's
>>  >> the large number of objectively small wins in `if` and `while`
>>  >> contexts.   They add up.  That conclusion surprised me.  That 
>> there are
>>  >> occasionally bigger wins to be had is pure gravy.
>> [Serhiy Storchaka]
>>  > Could you please show me several examples in real code? I
>>  > have not seen any win yet.
>> My PEP Appendix was derived entirely from looking at real code. If 
>> you don't believe the examples I showed there are wins (and I don't 
>> know whether you've seen them, because your original message in this 
>> thread only echoed examples from the body of the PEP), then what we 
>> each mean by "win" in this context has no intersection, so discussing 
>> it would be futile (for both of us).
> Sorry, this PEP was rewritten so many times that I missed your Appendix.
>> while total != (total := total + term):
>>     term *= mx2 / (i*(i+1))
>>     i += 2
>> return total
> This code looks clever that the original while loop with a break in a 
> middle. I like clever code. But it needs more mental efforts for 
> understanding it.
> I admit that this is a good example.
> There is a tiny problem with it (and with rewriting a while loop as a 
> for loop, as I like). Often the body contains not a single break. In 
> this case the large part of cleverness is disappeared. :-(

It took me a few minutes to figure out that this construct actually 
checks term == 0.

So, this example abuses the construct to do something it's not designed 
to do: perform an unrelated operation before checking the condition.
(Cue attempts to squeeze ever mode code here.) I would fail it in review.

This "clever" code is exactly what Perl burned itself on and what 
Python, being its antithesis, was specifically designed to avoid.

>> if result := solution(xs, n):
>>     # use result
> It looks equally clear with the original code. This is not enough for 
> introducing a new syntax.
>> if reductor := dispatch_table.get(cls):
>>     rv = reductor(x)
>> elif reductor := getattr(x, "__reduce_ex__", None):
>>     rv = reductor(4)
>> elif reductor := getattr(x, "__reduce__", None):
>>     rv = reductor()
>> else:
>>     raise Error("un(shallow)copyable object of type %s" % cls)
> I was going to rewrite this code as
>     reductor = dispatch_table.get(cls)
>     if reductor:
>         rv = reductor(x)
>     else:
>         rv = x.__reduce_ex__(4)
> There were reasons for the current complex code in Python 2, but now 
> classic classes are gone, and every class has the __reduce_ex__ method 
> which by default calls __reduce__ which by default is inherited from 
> object. With that simplification the benefit of using ":=" in this 
> example looks less impressed.
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>>     return g
>> while a > (d := x // a**(n-1)):
>>     a = ((n-1)*a + d) // n
>> return a
> I would have a fun writing such code. As well as I believe you had a 
> fun writing it. But I suppose the original code is simpler for a 
> casual reader, and I will refrain from using such code in a project 
> maintained by other people (in particular in the Python stdlib).
>> Which is what I expect:  the treatment you gave to the examples from 
>> the body of the PEP suggests you're determined not to acknowledge any 
>> "win", however small.
> I have to admit that *there are* examples that can have a small win. I 
> wondering why your examples are not used in the PEP body instead of 
> examples which play *against* PEP 572.
> Yet a win too small to me for justifying such syntax change. I know 
> that I can not convince you or Guido.
> _______________________________________________
> 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


More information about the Python-Dev mailing list