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

Reading this sub-thread, it struck me that a good way to make PEP 562 more likely to be accepted is to launch an over-the-top attack on it. Then more moderate people - who were/are not necessarily in favour of the PEP - feel pressurised into defending it. Hah! Watch this space for my vicious,

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

On Sat, Apr 28, 2018 at 9:18 PM, Ned Batchelder wrote: > It's entirely true that binding expressions don't change this situation at > all, EXCEPT that the entire point of binding expressions is to be able to > express in one statement what used to take more than one. With

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

On 4/27/18 5:28 PM, Tres Seaver wrote: On 04/27/2018 05:11 PM, Tim Peters wrote: 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

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

On Fri, Apr 27, 2018 at 8:19 PM, Tim Peters wrote: > [Lukasz] > >> > And that *is* a thing that you will have to explain to newbies when > >> > they encounter it for the first time. > > ​Which they will presumably do either in class or by reading code. No sensible

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

On Fri, Apr 27, 2018 at 04:24:35PM -0400, Wes Turner wrote: > if ((1) or (x := 3)): > if ((y := func(x)) if x else (x := 3)) Wes, there is *absolutely nothing new* here. This sort of error is already possible in Python. Do you see a lot of code like: if (1 or sequence.append(3) or

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

Hi, 2018-04-28 5:08 GMT+02:00 Armin Rigo : > Hi, > > On 26 April 2018 at 07:50, Raymond Hettinger > wrote: > >> [Raymond Hettinger ] > >>> After re-reading all the proposed code samples, I believe that > >>>

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

Hi, On 26 April 2018 at 07:50, Raymond Hettinger wrote: >> [Raymond Hettinger ] >>> After re-reading all the proposed code samples, I believe that >>> adopting the PEP will make the language harder to teach to people >>> who are not

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

On 4/27/2018 2:11 PM, Tim Peters wrote: 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;-) You're getting pretty good at that QOTD thing, Tim :)

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

It's certainly a contrived example. Actual code with such a mistake is generally far more subtle. The mistake is that it's assigning a value within a clause of a conditional that won't be evaluated. Oh well. I'll suffer the then worsened zig-zaggy eye movements in code reviews caused by defining

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

[Tres Seaver ] > FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage. > I haven't seen anything in this discussion which indicates that binding > expressions will change that at all. I don't think you missed anything relevant either ;-) Binding

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

Wes, sorry, but I really don't follow what you're saying. For example, [Wes Turner ] > Do not do this: > > x = 2 > if (x == 3) or (x := 3): >print(x) > > What do we call that mistake? It displays 3 - while it appears to be silly code, there's nothing about it that's

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

On 04/27/2018 05:11 PM, Tim Peters wrote: > 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

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

On Sat, Apr 28, 2018 at 7:11 AM, Tim Peters wrote: > [Chris Angelico ] >> ... >> 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

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

On Friday, April 27, 2018, Tim Peters wrote: > [Chris Angelico ] > > ... > > 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

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

[Chris Angelico ] > ... > 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,

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

On Sat, Apr 28, 2018 at 6:24 AM, Wes Turner wrote: > > > On Friday, April 27, 2018, Chris Angelico wrote: >> >> On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote: >> > >> > >> > On Friday, April 27, 2018, Chris Angelico

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

On Friday, April 27, 2018, Chris Angelico wrote: > On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote: > > > > > > On Friday, April 27, 2018, Chris Angelico wrote: > >> > >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner

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

On Sat, Apr 28, 2018 at 6:06 AM, Wes Turner wrote: > > > On Friday, April 27, 2018, Chris Angelico wrote: >> >> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote: >> > IDK, I could just be resistant to change, but this seems like

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

On Friday, April 27, 2018, Chris Angelico wrote: > On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner wrote: > > IDK, I could just be resistant to change, but this seems like something > that > > will decrease readability -- and slow down code review -- without

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

[Lukasz] >> > And that *is* a thing that you will have to explain to newbies when >> > they encounter it for the first time. [Tim] >> Sure. That doesn't frighten me, though. It's easy to explain what it >> does - although it may be hard to explain when it's _desirable_ to use >> it. [Chris

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

On Thu, Apr 26, 2018 at 1:33 PM, Tim Peters wrote: > And that *is* a thing that you will have to explain to newbies when they > encounter > > it for the first time. > > Sure. That doesn't frighten me, though. It's easy to explain what it > does - although it may be hard

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

On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner 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

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

So, the style guidelines for this new feature -- and also ternary expressions and comprehension -- would need to mention that: - debuggers have no idea what to do with all of this on one line - left-to-right doesn't apply to comprehensions results = [(x, y, x/y) for x in input_data if (y :=

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

On Thu, Apr 26, 2018 at 08:48:12AM -0700, Łukasz Langa wrote: > > > On Apr 25, 2018, at 11:10 PM, Steven D'Aprano wrote: > > Criticising binding- > > expressions for that reason, especially implying that we must always use > > parens, is simply FUD. > > The PEP has more

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

[Zero Piraeus] >> Since it now looks like it really *does* have a decent chance, and >> maybe another -1 has a small chance of tipping the balance: my >> reaction to the proposal is also emotional. Visceral, in fact, to the >> extent that I'd aim to read and write less Python if it became >>

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

On Thu, Apr 26, 2018 at 08:00:46PM +0100, Zero Piraeus wrote: > Since it now looks like it really *does* have a decent chance, and > maybe another -1 has a small chance of tipping the balance: my > reaction to the proposal is also emotional. Visceral, in fact, to the > extent that I'd aim to read

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

2018-04-26 13:20 GMT+03:00 Steve Holden : > On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano > wrote: > >> On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: >> > On 4/25/2018 8:20 PM, Chris Angelico wrote: >> > >On Thu, Apr 26, 2018 at 10:11

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

[Tim] >> So, to match your sarcasm, here's mine: try using a feature for what >> it's good at instead of for what it's bad at ;-) [Lukasz Langa ] > Yes, this is the fundamental wisdom. Judging which is which is left as an > exercise to the programmer. > > With this, I'm leaving

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

On 4/26/2018 6:34 AM, Greg Ewing wrote: Antoine Pitrou wrote: Well, how do languages where assignment is an expression returning the assigned value make their REPLs work?  I'm sure they don't inflict that on their users, so it's certainly a solvable problem. I can't think of any such language

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

: On 25 April 2018 at 21:28, Guido van Rossum wrote: > A very emotional appeal, you don't seem to grasp the usability improvements > this will give. I hear you but at this point appeals to Python's "Zen" don't > help you. I have to admit, in half-following this discussion I've

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

On 4/26/2018 6:20 AM, Steve Holden wrote: On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano > wrote: On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > On 4/25/2018 8:20 PM, Chris Angelico wrote: > >On Thu, Apr 26, 2018 at

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

[Uncle T] > So, to match your sarcasm, here's mine: try using a feature for what > it's good at instead of for what it's bad at ;-) Yes, this is the fundamental wisdom. Judging which is which is left as an exercise to the programmer. With this, I'm leaving the discussion. With Guido and you

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

> On Apr 25, 2018, at 11:10 PM, Steven D'Aprano wrote: > Criticising binding- > expressions for that reason, especially implying that we must always use > parens, is simply FUD. The PEP has more examples with parentheses than without. >> As soon as we have to wrap a part

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

On 26 April 2018 at 15:38, Chris Angelico wrote: > On Thu, Apr 26, 2018 at 3:34 PM, Steven D'Aprano wrote: >> Can you give an example of a Python expression, involving PEP 572 >> binding-expressions, that is not a tree but a more general DAG or that >>

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

FWIW, the combination of limiting the PEP to binding expressions and the motivating example of sequential if/elif tests that each need to utilize an expression in their body (e.g. matching various regexen by narrowing, avoiding repeated indent) gets me to +1. I still think the edge case changes

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

On Thu, Apr 26, 2018 at 10:34:29PM +1200, Greg Ewing wrote: > Antoine Pitrou wrote: > >Well, how do languages where assignment is an expression returning the > >assigned value make their REPLs work? I'm sure they don't inflict that > >on their users, so it's certainly a solvable problem. > > I

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

On Thu, Apr 26, 2018 at 10:17:34AM +0200, Antoine Pitrou wrote: > I also wonder how long it will be before someone writes: > > def f(arg): > global _lazy_value > if predicate(arg) and (_lazy_value := frobnicate()) > arg: > ... > > (or something similar with

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

> > [Raymond Hettinger ] > > Python is special, in part, because it is not one of those languages. > > It has virtues that make it suitable even for elementary school children. > > We can show well-written Python code to non-computer folks and walk > > them through

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

Łukasz Langa writes: > > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > You're claiming that `:=` is nicer in this situation because it's less > prominent than regular assignment and thus doesn't suggest that the name > stays visible later. FWIW, I read what he wrote

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

Antoine Pitrou wrote: Depends if you mean a graph between names or values? > If between names, you can even have cycles AFAICT: ((a: = a + b), (b: = a)) I was thinking more of the dataflow graph. That's not a cycle between *values*, since the new values being bound are calculated from the

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

Antoine Pitrou wrote: Well, how do languages where assignment is an expression returning the assigned value make their REPLs work? I'm sure they don't inflict that on their users, so it's certainly a solvable problem. I can't think of any such language that has a REPL offhand, but here's a

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

On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > > On 4/25/2018 8:20 PM, Chris Angelico wrote: > > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > > wrote: > > >>Just

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

On Wed, Apr 25, 2018 at 9:55 PM, Łukasz Langa wrote: > > > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > > > You don't seem to grasp the usability improvements this will give. I > hear you but at this point appeals to Python's "Zen" don't help you.

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

On Thu, 26 Apr 2018 19:19:05 +1000 Chris Angelico wrote: > > > > If such were the need, you could very well make it part of the language > > specification. We are talking about a trivial optimization that any > > runtime could easily implement (e.g. if a sequence `DUP_TOP,

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

On Thu, Apr 26, 2018 at 6:30 PM, Antoine Pitrou wrote: > On Thu, 26 Apr 2018 17:29:17 +1000 > Steven D'Aprano wrote: >> On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: >> > Tim Peters wrote: >> > >As a statement in a program (as opposed to

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

On Thu, 26 Apr 2018 15:34:17 +1000 Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: > > Łukasz Langa wrote: > > >What was its own assignment before > > >now is part of the logic test. This saves on vertical whitespace but makes > >

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

On Thu, 26 Apr 2018 17:29:17 +1000 Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: > > Tim Peters wrote: > > >As a statement in a program (as opposed to typed at a shell), > > >"a := 3" has the unnecessary (in that context) property of

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

On Wed, 25 Apr 2018 18:52:34 -0700 Łukasz Langa wrote: > > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > > > > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > wrote: > >> Just yesterday this snippet was used on

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

On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > On 4/25/2018 8:20 PM, Chris Angelico wrote: > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > wrote: > >>Just yesterday this snippet was used on python-dev to show how great the > >>new syntax is: > >> >

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

On 4/25/2018 8:20 PM, Chris Angelico wrote: On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov wrote: Just yesterday this snippet was used on python-dev to show how great the new syntax is: my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) What

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

On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: > Tim Peters wrote: > >As a statement in a program (as opposed to typed at a shell), > >"a := 3" has the unnecessary (in that context) property of returning > >(and discarding 3), so it's better style to use "a = 3" in that > >context. >

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

Tim Peters wrote: To my eyes, this is genuinely harder to follow, despite its relative brevity: while total != (total := total + term): Not surprising, since there are at least two deeper levels of subtlety at play: 1. total isn't just naming a subexpression, it's being rebound to

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

Tim Peters wrote: As a statement in a program (as opposed to typed at a shell), "a := 3" has the unnecessary (in that context) property of returning (and discarding 3), so it's better style to use "a = 3" in that context. That seems like a post-hoc justification. If := were the one and only

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

[Raymond Hettinger ] >>> After re-reading all the proposed code samples, I believe that >>> adopting the PEP will make the language harder to teach to people >>> who are not already software engineers. [Tim] >> Can you elaborate on that? [Raymond] > Just

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

Łukasz Langa wrote: Ha, not in Python! Here we have *different syntax* for assignments in expressions. Well, you can also use it as a statement. But don't! This is what I least like about the proposal. We should be moving in the direction of removing warts, but here we would be *creating* one

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

On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov wrote: my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) Obviously what we want here is a variant of the binding expression that also makes it a keyword argument: my_func(arg, buffer ::=

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

On Wed, Apr 25, 2018 at 10:14:11PM -0700, Łukasz Langa wrote: > So only use the Pascal one in expressions. But don't forget > parentheses, otherwise it will bind the thing you probably didn't want > anyway. Binding expressions are no worse than any other expression: sometimes you need to

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

[Tim] >> One language feature conspicuous by absence in newbie >> confusions was, consistently, assignment expressions. Read any book >> or tutorial for such a language, and you'll find very little space >> devoted to them too. [Łukasz Langa ] > Well, you have an entire code

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

> On Apr 26, 2018, at 12:40 AM, Tim Peters wrote: > > [Raymond Hettinger ] >> After re-reading all the proposed code samples, I believe that >> adopting the PEP will make the language harder to teach to people >> who are not already software

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

On Thu, Apr 26, 2018 at 3:34 PM, Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: >> Łukasz Langa wrote: >> >What was its own assignment before >> >now is part of the logic test. This saves on vertical whitespace but makes >> >parsing and

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

On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: > Łukasz Langa wrote: > >What was its own assignment before > >now is part of the logic test. This saves on vertical whitespace but makes > >parsing and understanding logic tests harder. > > Another way to say this is that expressions

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

Łukasz Langa wrote: What was its own assignment before now is part of the logic test. This saves on vertical whitespace but makes parsing and understanding logic tests harder. Another way to say this is that expressions are no longer restricted to being trees, but can be general DAGs, which

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

[Uncle T] > One language feature conspicuous by absence in newbie > confusions was, consistently, assignment expressions. Read any book > or tutorial for such a language, and you'll find very little space > devoted to them too. Well, you have an entire code style built around this feature called

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

[Raymond Hettinger ] > After re-reading all the proposed code samples, I believe that > adopting the PEP will make the language harder to teach to people > who are not already software engineers. Can you elaborate on that? I've used dozens of languages over the

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

> On Apr 25, 2018, at 8:11 PM, Yury Selivanov wrote: > > FWIW I started my thread for allowing '=' in expressions to make sure that > we fully explore that path. I don't like ':=' and I thought that using '=' > can make the idea more appealing to myself and others. It

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

On Wednesday, April 25, 2018, Łukasz Langa wrote: > > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > wrote: > > Just yesterday this snippet was used on python-dev to show how

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

> On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > wrote: >> Just yesterday this snippet was used on python-dev to show how great the >> new syntax is: >> >> my_func(arg, buffer=(buf

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

On Wed, Apr 25, 2018 at 8:22 PM Chris Angelico wrote: [..] > > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) > > > > To my eye this is an anti-pattern. One line of code was saved, but the > > other line becomes less readable. The fact that 'buf' can

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

On Thu, 26 Apr 2018 10:20:40 +1000 Chris Angelico wrote: > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > wrote: > > Just yesterday this snippet was used on python-dev to show how great the > > new syntax is: > > > > my_func(arg,

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

On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov wrote: > Just yesterday this snippet was used on python-dev to show how great the > new syntax is: > > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) > > To my eye this is an anti-pattern. One

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

On Wed, 25 Apr 2018 18:55:56 -0500 Tim Peters wrote: > > > the shorthand version appears completely bonkers. > > I wouldn't go that far, but I already said I wouldn't write it that way. > > However, without looking at real code, people are just flat-out > guessing about

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

On Wed, Apr 25, 2018 at 5:58 PM Guido van Rossum wrote: [..] > It was meant dismissive. With Chris, I am tired of every core dev starting their own thread about how PEP 572 threatens readability or doesn't reach the bar for new syntax (etc.). These arguments are entirely

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

[Tim] To my eyes, this is genuinely harder to follow, despite its relative brevity: while total != (total := total + term): [Antoine] >>> Does it even work? Perhaps if the goal is to stop when total is NaN, >>> but otherwise? [Chris] >> Yes, it does, because the

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

On Thu, 26 Apr 2018 08:38:51 +1000 Chris Angelico wrote: > On Thu, Apr 26, 2018 at 8:08 AM, Antoine Pitrou wrote: > > On Wed, 25 Apr 2018 16:55:43 -0500 > > Tim Peters wrote: > >> > >> To my eyes, this is genuinely harder to

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

On Wed, Apr 25, 2018 at 3:15 PM, Ethan Furman wrote: > On 04/25/2018 02:55 PM, Tim Peters wrote: > >> To my eyes, this is genuinely harder to follow, despite its relative >> brevity: >> >> while total != (total := total + term): >> term *= mx2 /

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

On Thu, Apr 26, 2018 at 8:08 AM, Antoine Pitrou wrote: > On Wed, 25 Apr 2018 16:55:43 -0500 > Tim Peters wrote: >> >> To my eyes, this is genuinely harder to follow, despite its relative brevity: >> >> while total != (total := total + term): > >

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

On 04/25/2018 03:15 PM, Ethan Furman wrote: On 04/25/2018 02:55 PM, Tim Peters wrote: This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common enough

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

[Tim] >> To my eyes, this is genuinely harder to follow, despite its relative brevity: >> >> while total != (total := total + term): [Antoine] > Does it even work? Perhaps if the goal is to stop when total is NaN, > but otherwise? I don't follow you. You snipped all the text explaining

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

On Wed, Apr 25, 2018 at 01:55:37PM -0700, Łukasz Langa wrote: > > > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > > > You don't seem to grasp the usability improvements this will give. I hear > > you but at this point appeals to Python's "Zen" don't help you. > >

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

On 04/25/2018 02:55 PM, Tim Peters wrote: This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common enough pattern in code slinging floats or decimals):

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

On Wed, 25 Apr 2018 16:55:43 -0500 Tim Peters wrote: > > To my eyes, this is genuinely harder to follow, despite its relative brevity: > > while total != (total := total + term): Does it even work? Perhaps if the goal is to stop when total is NaN, but otherwise?

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

On Wed, Apr 25, 2018 at 1:55 PM, Łukasz Langa wrote: > > > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > > > You don't seem to grasp the usability improvements this will give. I > hear you but at this point appeals to Python's "Zen" don't help you.

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

[Guido] >> You don't seem to grasp the usability improvements this will give. >> I hear you but at this point appeals to Python's "Zen" don't help you. [Łukasz Langa ] > This reads dismissive to me. I did read the PEP and followed the discussion on > python-dev. I referred to PEP

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

> On 25 Apr, 2018, at 1:24 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 6:21 AM, Łukasz Langa wrote: >> := also goes against having one obvious way to do it. Since it's an >> expression, >> it can also be placed on its own line or in otherwise weird

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

> On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > You don't seem to grasp the usability improvements this will give. I hear you > but at this point appeals to Python's "Zen" don't help you. This reads dismissive to me. I did read the PEP and followed the discussion

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

A very emotional appeal, you don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you. On Wed, Apr 25, 2018 at 1:21 PM, Łukasz Langa wrote: > PEP 572 caused a strong emotional reaction in me. I wanted

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

On Thu, Apr 26, 2018 at 6:21 AM, Łukasz Langa wrote: > := also goes against having one obvious way to do it. Since it's an > expression, > it can also be placed on its own line or in otherwise weird places like > function call arguments. I anticipate PEP 8 would have to be

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

PEP 572 caused a strong emotional reaction in me. I wanted to first understand my intuitive objection to the idea before posting anything. I feel that (name := expression) doesn't fit the narrative of PEP 20. It doesn't remove complexity, it only moves it. What was its own assignment before now