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

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 := 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 = dispatchtable.get(cls) if reductor: rv = reductor(x) else: rv = x.reduceex(4) There were reasons for the current complex code in Python 2, but now classic classes are gone, and every class has the reduceex 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.

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

More information about the Python-Dev mailing list