[Python-Dev] Examples for PEP 572
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 пише:
>> >> I really don't know what Guido likes best about this, but for me
>> >> 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()
>> 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)
> 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
More information about the Python-Dev