On Friday, April 27, 2018, Tim Peters <tim.peters@gmail.com> wrote:
[Chris Angelico <rosuav@gmail.com>]
> ...
> I don't understand why people bring up all these arguments that have
> absolutely nothing to do with the proposal at hand. None of this has
> in any way changed.

That's easy:  any time there's a long thread to which Guido has
contributed at least twice, it will be seen as a Golden Opportunity to
re-litigate every decision that's ever been made ;-)

Some amount of that seems healthy to me (people are thinking about
"language design" from a larger view than the proposal du jour).  In
this specific case, line-oriented coverage tools have missed
accounting for all possible code paths since day #1; e.g.,

    x = f() or g()

You don't need to reply to messages so obviously irrelevant to the PEP
unless you want to.  It's not like Guido will read them and go "oh!  a
binding expression in a ternary conditional is a fundamentally new
potential problem for a line-oriented coverage tool!  that's fatal"

I have shared with you the overlapping concerns about this feature proposal that I believe should be explained with DO and DON'T in the docs and/or the PEP and/or the style guide(s) for various organizations in the Pyrhon community.

This feature does require additions to the style-guide(s); which is why so many have expressed concern about such a simple thing.

If you want to write debuggable and coverage-testable code, do not use the assignment expression operator in ternary expressions or boolean-chained expressions.

The assignment expression operator is the only way to define variables with only comprehension scope.

Do not do this:

x = 2
if (x == 3) or (x := 3):

What do we call that mistake?
Python-Dev mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com