RetroSearch Browse

Wed Jul 4 04:54:34 EDT 2018 · https://mail.python.org/pipermail/python-dev/2018-July/154266.html

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

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-July/154266.html below:

[Python-Dev] Examples for PEP 572