[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20 (original) (raw)
Chris Angelico rosuav at gmail.com
Fri Apr 27 16:29:54 EDT 2018
- Previous message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Next message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Next message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]