[Python-Dev] Examples for PEP 572 (original) (raw)

Serhiy Storchaka storchaka at gmail.com
Wed Jul 4 04:54:34 EDT 2018

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 := dispatchtable.get(cls): rv = reductor(x) elif reductor := getattr(x, "reduceex", 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 - xbase) 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.

More information about the Python-Dev mailing list