[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Chris Angelico]

On Sat, Apr 28, 2018 at 6:24 AM, Wes Turner <wes.turner at gmail.com> wrote:
>
>
> On Friday, April 27, 2018, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner <wes.turner at gmail.com> wrote:
>> >
>> >
>> > On Friday, April 27, 2018, Chris Angelico <rosuav at gmail.com> wrote:
>> >>
>> >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner <wes.turner at gmail.com>
>> >> wrote:
>> >> > IDK, I could just be resistant to change, but this seems like
>> >> > something
>> >> > that
>> >> > will decrease readability -- and slow down code review -- without any
>> >> > real
>> >> > performance gain. So, while this would be useful for golfed-down (!)
>> >> > one-liners with pyline,
>> >> > I'm -1 on PEP 572.
>> >>
>> >> PEP 572 has never promised a performance gain, so "without any real
>> >> performance gain" is hardly a criticism.
>> >>
>> >> > How do I step through this simple example with a debugger?
>> >> >
>> >> >     if re.search(pat, text) as match:
>> >> >         print("Found:", match.group(0))
>> >>
>> >> Step the 'if' statement. It will call re.search() and stash the result
>> >> in 'match'. Then the cursor would be put either on the 'print' (if the
>> >> RE matched) or on the next executable line (if it didn't).
>> >
>> >
>> > Right. Pdb doesn't step through the AST branches of a line, so ternary
>> > expressions and list comprehensions and defining variables at the end of
>> > the
>> > line are 'debugged' after they're done.
>> >
>> > Similarly, code coverage is line-based; so those expressions may appear
>> > to
>> > be covered but are not.
>>
>> I'm not sure I follow. In what situation would some code appear to be
>> covered when it isn't, due to an assignment expression?
>
>
> When an assignment expression is in the else clause of a ternary expression,
> but the else clause does not execute because the condition is true, the
> assignment expression does not execute and so isn't covered.
>
> if ((1) or (x := 3)):
> if ((y := func(x)) if x else (x := 3))
>
> Is this a new opportunity for misunderstanding?
>
> Assignment expressions, though they are noticeable :=, may not actually
> define the variable in cases where that part of the line doesn't run but
> reads as covered.

Okay. How is this different from anything else involving if/else
expressions? If your code coverage checker is unable to handle
if/else, it's unable to handle it whether there's an assignment in
there or not.

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.

ChrisA