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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
