On 2018-04-11 05:23, Clint Hepner wrote:
I find the assignments make it difficult to pick out what the final expression
I strongly agree with this, and for me I think this is enough to push
me to -1 on the whole proposal. For me the classic example case is
still the quadratic formula type of thing:
x1, x2 = (-b + sqrt(b**2 - 4*a*c))/2, (-b - sqrt(b**2 - 4*a*c))/2
It just doesn't seem worth it to me to create an expression-level
assignment unless it can make things like this not just less verbose but
at the same time more readable. I don't consider this more readable:
x1, x2 = (-b + sqrt(D := b**2 - 4*a*c)))/2, (-b - sqrt(D))/2
. . . because having to put the assignment inline creates a visual
asymmetry, when for me the entire goal of an expression-level statement
is to make the symmetry between such things MORE obvious. I want to be
able to write:
x1, x2 = (-b + sqrt(D)))/2, (-b - sqrt(D))/2 ...
. . . where "..." stands for "the part of the expression where I define
the variables I'm re-using in multiple places in the expression".
The new proposal does at least have the advantage that it would help
with things like this:
while x := some_function_call():
# do stuff
So maybe I'm -0.5 rather than -1. But it's not just that this proposal
"could be used to create ugly code". It's that using it for
expression-internal assignments WILL create ugly code, and there's no
way to avoid it. I just don't see how this proposal provides any way to
make things like the quadratic formula example above MORE readable.
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/