[Python-ideas] Fwd: Pattern Matching Syntax

2018-05-11 Thread Jelle Zijlstra
2018-05-11 22:01 GMT-04:00 Robert Roskam : > Hey Steven, > > I'm also at PyCon. Shall we take this off list and attempt to meet up and > discuss? > > I'm also at PyCon and interested in meeting about this. I just wrote up a basic and incomplete implementation for

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Tim Peters
[Tim[ >> ... >> ":=" target names in a genexp/listcmp are treated exactly the same as >> any other non-for-target name: they resolve to the same scope as they >> resolve to in the block that contains them. The only twist is that if >> such a name `x` isn't otherwise known in the block, then `x`

Re: [Python-ideas] Pattern Matching Syntax

2018-05-11 Thread Robert Roskam
Hey Steven, I'm also at PyCon. Shall we take this off list and attempt to meet up and discuss? On Friday, May 11, 2018 at 12:36:32 PM UTC-4, ste...@rigetti.com wrote: > > Hi everyone, I’m also a first time poster to python-ideas so I apologize > if reviving a week old thread is bad form. I

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Rob Cliffe via Python-ideas
Yeah, well, I'm totally lost.  Even after trying out this code, and refactoring it once if not twice, I didn't understand it.  I don't know what point you're trying to prove, but you seem to have comprehensively proved it. On 11/05/2018 15:04, Jacco van Dorp wrote: A while ago, we had this

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Eric V. Smith
On 5/11/18 5:12 PM, Angus Hollands wrote: *Readability:* A smaller point is that I don't feel that ":=" is very readable. If we had to use an operator, I think $= is better, but me reasoning for this is weak. I think it derives from my observation that ":=" is slow to distinguish from "=". :=

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Juancarlo Añez
> > while (cmd := get_command()).token != CMD_QUIT: > > cmd.do_something() > > while get_command() as cmd: if cmd.token == CMD_QUIT: break cmd.do_something() -- Juancarlo *Añez* ___ Python-ideas mailing list

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Tim Peters
[Matt Arcidy] >> Note Tim came up with a real metric: >> 2 * count(":=")/len(statement). >> It's objective. it's just unclear if a higher score is better or worse. >> However, one could say "a Tim of .3 is considered too high" as a guideline. [Steven D'Aprano] > I think Tim was making a joke

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Sat, May 12, 2018 at 07:44:24AM +1000, Chris Angelico wrote: > (I'm still fairly sure that "explicit" and "strongly typed" are both > synonyms for "stuff I like", with their antonyms "implicit" and > "weakly typed" both being synonyms for "stuff I don't like". Years of > discussion have not

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 11, 2018 at 01:42:55PM -0400, Alexander Belopolsky wrote: > On Fri, May 11, 2018 at 11:43 AM Steven D'Aprano > wrote: > > ... > > I agree with Jacco here. We have to name the variable twice, even if it > > is only used once, and we have a relatively long keyword,

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 11, 2018 at 11:52:02AM -0700, Matt Arcidy wrote: > Note Tim came up with a real metric: > 2 * count(":=")/len(statement). > It's objective. it's just unclear if a higher score is better or worse. > However, one could say "a Tim of .3 is considered too high" as a guideline. I think

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Chris Angelico
On Sat, May 12, 2018 at 7:56 AM, Ed Kellett wrote: >> *Readability:* >> A smaller point is that I don't feel that ":=" is very readable. If we had >> to use an operator, I think $= is better, but me reasoning for this is >> weak. I think it derives from my observation

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Ed Kellett
On 2018-05-11 22:12, Angus Hollands wrote: > while (value:=get_next_pool_item()) and value.in_use: > print(value.refcount()) Just as a heads-up, I believe the prescribed way of doing that is: while (value := get_next_pool_item()).in_use: Of course you'd need additional mess to do

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Chris Angelico
On Sat, May 12, 2018 at 7:12 AM, Angus Hollands wrote: > e.g > > while value.in_use given value = get_next_pool_item(): > print(value.refcount()) > > Instead of > > while (value:=get_next_pool_item()) and value.in_use: > print(value.refcount()) > > In addition, the two

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Angus Hollands
wing <greg.ew...@canterbury.ac.nz> > wrote: > > > Guido van Rossum wrote: > > > >> I'd need well-reasoned explanations > >> > > > > My reasoning is essentially the same as what I've already > > said about "where". To summarise, "given" so

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Ryan Gonzalez
On May 11, 2018 1:45:27 PM Tim Peters wrote: [Brendan Barnwell] . . . and it's true the latter is a bit more verbose in that case for little extra benefit. But when the locally-defined value is used within a more complicated expression (like the quadratic formula

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Matt Arcidy
Apology for top post, but this is a general statement about Readability and not a response to an individual. it would be nice to list the objective parts separate from the "argument" (i.e. debate, not fight), perhaps list them then make a case for which metric is a more important, and which

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Tim Peters
[Brendan Barnwell] >> >> . . . and it's true the latter is a bit more verbose in that case for >> little extra benefit. But when the locally-defined value is used within >> a more complicated expression (like the quadratic formula example), I >> think readability goes down significantly. To

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Brendan Barnwell
On 2018-05-11 11:08, Brendan Barnwell wrote: . . . and it's true the latter is a bit more verbose in that case for little extra benefit. But when the locally-defined value is used within a more complicated expression (like the quadratic formula example), I think readability goes down

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Brendan Barnwell
On 2018-05-11 09:17, Steven D'Aprano wrote: Much earlier in the PEP 572 discussion, I strongly argued in favour of the expr as name syntax on the basis that the most important part of the overall expression is "expr", not the assignment target, and therefore that should come first. Even

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Alexander Belopolsky
On Fri, May 11, 2018 at 11:43 AM Steven D'Aprano wrote: > ... > I agree with Jacco here. We have to name the variable twice, even if it > is only used once, and we have a relatively long keyword, five > characters, longer than average for all keywords, and only one char >

Re: [Python-ideas] PEP 572: about the operator precedence of :=

2018-05-11 Thread Steven D'Aprano
On Thu, May 10, 2018 at 09:53:40AM -0400, Guido van Rossum wrote: [...] > So all in all I'm not sure I think this is important enough to support, and > the rule "Use `:=` in expressions, not as a top level assignment" seems > easier to explain and understand. Like Terry, I too would find it

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Rhodri James
On 11/05/18 15:04, Jacco van Dorp wrote: A while ago, we had this gem: 2018-04-06 8:19 GMT+02:00 Serhiy Storchaka: Using currently supported syntax: smooth_signal = [average for average in [0] for x in signal for average in [(1-decay)*average + decay*x]] Go ahead

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 11, 2018 at 12:33:10PM -0400, Guido van Rossum wrote: > A thought just occurred to me. Maybe we need to instigate a cultural shift > where people think about style guides as less dictated by hard-coded rules > that were "passed down from the mountain" and more as derived from research

Re: [Python-ideas] Pattern Matching Syntax

2018-05-11 Thread steven
Hi everyone, I’m also a first time poster to python-ideas so I apologize if reviving a week old thread is bad form. I emailed Guido out of the blue to share some thoughts on the JavaScript pattern matching proposal’s applicability to Python and he encouraged me to post those thoughts here. The

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Tim Peters
[Gustavo Carneiro] >>> IMHO, all these toy examples don't translate well to the real world >>> because they tend to use very short variable names while in real world [good >>> written code] tends to select longer more descriptive variable names. [Greg Ewing] >> I don't believe that's always true.

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 11, 2018 at 03:47:05PM +0200, João Santos wrote: > How do you read something like " while (cmd := get_command()).token != > CMD_QUIT:" in plain english? I wouldn't if I could avoid it. I hardly ever program by talking about code in plain English. Often the lines are gobblydegook:

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Guido van Rossum
On Fri, May 11, 2018 at 3:33 AM, Greg Ewing wrote: > Most people's short-term memory is good enough to remember > that "m" refers to the match object while they read the > next couple of lines. IMO, using a longer name would serve > no purpose and would just clutter

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Guido van Rossum
Maybe you could propose some kind of syntax using "whereas"? (It can be used as a preamble.) On Fri, May 11, 2018 at 3:05 AM, Greg Ewing wrote: > Guido van Rossum wrote: > >> I'd need well-reasoned explanations >> > > My reasoning is essentially the same as what

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 11, 2018 at 12:37:43PM +0100, Rhodri James wrote: > Consider: > > while (cmd := get_command()).token != CMD_QUIT: > cmd.do_something() > > vs: > > while cmd.token != CMD_QUIT given cmd = get_command(): > cmd.do_something() Okay, considered. I think the first is

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Chris Angelico
On Sat, May 12, 2018 at 12:04 AM, Jacco van Dorp wrote: >> [João] >> How do you read something like " while (cmd := get_command()).token != >> CMD_QUIT:" in plain english? > > while open-paren cee em dee colon is call get-underscore-command > close-paren dot token doesn't

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 11, 2018 at 11:40:51AM +0200, Jacco van Dorp wrote: > I dont really like "given". > > If we compare: > > if m given m = re.match(stuff): > > to > > if m := re.match(stuff) > > then I count 4+(name_length) more tokens and 2 more spaces. Since I > believe := is perfectly clear, I

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Thu, May 10, 2018 at 10:31:00PM -0400, Nick Malaguti wrote: > One of my hurdles for ":=" is understanding when I should use it rather > than "=". Should I use it everywhere? Should I use it only where I can't > use regular "="? Is it a personal choice? Will it become so common that > I need

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Kirill Balunov
2018-05-11 17:06 GMT+03:00 Clint Hepner : > > > (This reminds that I wish ``iter`` could take a predicate instead of a > sentinel as its second argument. Then > you could just write > > for cmd in iter(get_command, lambda x: x.token == CMD_QUIT): >

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Jacco van Dorp
A while ago, we had this gem: 2018-04-06 8:19 GMT+02:00 Serhiy Storchaka : > Using currently supported syntax: > > smooth_signal = [average for average in [0] for x in signal for average > in [(1-decay)*average + decay*x]] Go ahead and understand that line in 1 go. It's

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Guido van Rossum
(Note: this is an off-topic side thread, unrelated to assignment expressions. Inline comment below.) On Fri, May 11, 2018 at 9:08 AM, Chris Angelico wrote: > On Fri, May 11, 2018 at 9:15 PM, Nick Coghlan wrote: > > * *maybe* discover that even the above

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread João Santos
How do you read something like " while (cmd := get_command()).token != CMD_QUIT:" in plain english? On Fri, 11 May 2018 at 12:15 Jacco van Dorp wrote: > 2018-05-11 11:56 GMT+02:00 João Santos : > > Optimizing syntax for space makes sense for "mathematical"

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Rhodri James
On 11/05/18 14:25, Jacco van Dorp wrote: I actually have to mentally parse the entire line to get what the check will work. This, along with what Chris said about order of operations, reduce the readability of the "given" version. You say "I had to parse the entire line..." I hear "I had to

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Jacco van Dorp
>[Rhodri] > I respectfully disagree with your opinion (i.e. you're wrong :-) > > Consider: > > while (cmd := get_command()).token != CMD_QUIT: > cmd.do_something() > > vs: > > while cmd.token != CMD_QUIT given cmd = get_command(): > cmd.do_something() > Actually, the first version is

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Chris Angelico
On Fri, May 11, 2018 at 9:15 PM, Nick Coghlan wrote: > * *maybe* discover that even the above expansion isn't quite accurate, and > that the underlying semantic equivalent is actually this (one way to > discover this by accident is to have a name error in the outermost

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Chris Angelico
On Fri, May 11, 2018 at 9:37 PM, Rhodri James wrote: > On 11/05/18 11:14, Jacco van Dorp wrote: >> >> 2018-05-11 11:56 GMT+02:00 João Santos : >>> >>> Optimizing syntax for space makes sense for "mathematical" notation since >>> it's commonly written by

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Fri, May 04, 2018 at 09:56:10PM -0400, Alexander Belopolsky wrote: > This proposal has finally made me realize why I did not > like PEP 572. The strong expression vs. statement dichotomy is one of > the key features that set Python apart from many other languages and > it makes Python

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Sven R. Kunze
On 11.05.2018 13:43, Nick Coghlan wrote: I've been thinking about this problem, and I think for the If/elif/while cases it's actually possible to allow the "binding is the same as the condition" case to be simplified to:     if command =  pattern.match(the_string):     ...     elif

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Steven D'Aprano
On Sat, May 05, 2018 at 06:24:07AM -0400, Juancarlo Añez wrote: > I think that "expr as y" was discarded too quickly. This discussion started back in *February*. I don't think "too quickly" applies to ANYTHING about it. https://mail.python.org/pipermail/python-ideas/2018-February/048971.html

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Nick Coghlan
On 11 May 2018 at 03:33, Greg Ewing wrote: > Gustavo Carneiro wrote: > >> IMHO, all these toy examples don't translate well to the real world >> because they tend to use very short variable names while in real world >> [good written code] tends to select longer more

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Rhodri James
On 11/05/18 11:14, Jacco van Dorp wrote: 2018-05-11 11:56 GMT+02:00 João Santos : Optimizing syntax for space makes sense for "mathematical" notation since it's commonly written by hand, but putting space above readability in a programming language design feels like a

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Nick Coghlan
On 11 May 2018 at 07:15, Nick Coghlan wrote: > * *maybe* discover that even the above expansion isn't quite accurate, and > that the underlying semantic equivalent is actually this (one way to > discover this by accident is to have a name error in the outermost iterable >

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Nick Coghlan
On 10 May 2018 at 23:47, Tim Peters wrote: > ... > > [Guido] > >> You should really read Tim's initial post in this thread, where he > >> explains his motivation. > > [Nick] > > I did, and then I talked him out of it by pointing out how confusing it > > would be to have the

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Sven R. Kunze
On 11.05.2018 09:38, Greg Ewing wrote: Kirill Balunov wrote: While for those who are familiar with Pascal, Icon and other languages that use this syntax, this - `:=` looks natural. As someone familiar with Pascal, I think the similarity to the Pascal assignment operator is actually an

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Ed Kellett
On 2018-05-10 17:10, Gustavo Carneiro wrote: > IMHO, all these toy examples don't translate well to the real world because > they tend to use very short variable names while in real world [good > written code] tends to select longer more descriptive variable names. > > Try replacing "c" with a

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Sven R. Kunze
On 11.05.2018 09:33, Greg Ewing wrote: Gustavo Carneiro wrote: IMHO, all these toy examples don't translate well to the real world because they tend to use very short variable names while in real world [good written code] tends to select longer more descriptive variable names. I don't

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Jacco van Dorp
2018-05-11 11:56 GMT+02:00 João Santos : > Optimizing syntax for space makes sense for "mathematical" notation since > it's commonly written by hand, but putting space above readability in a > programming language design feels like a skewmorphism. You are assuming "given" to

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread João Santos
Optimizing syntax for space makes sense for "mathematical" notation since it's commonly written by hand, but putting space above readability in a programming language design feels like a skewmorphism. On Fri, 11 May 2018 at 11:41 Jacco van Dorp wrote: > I dont really like

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Jacco van Dorp
I dont really like "given". If we compare: if m given m = re.match(stuff): to if m := re.match(stuff) then I count 4+(name_length) more tokens and 2 more spaces. Since I believe := is perfectly clear, I don't see the reason for a far more verbose syntax. That all said, I would still prefer:

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread João Santos
+1 to this reasoning. One of the main reason python is popular is because code is easy to read, while ":=" would clearly not be as readable as "given". For me the difference between "given" and ":=" is the same as between python and C for loops. On Fri, 11 May 2018 at 09:06 Greg Ewing

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Tim Peters
[Tim] >> Since this is all about scope, while I'm not 100% sure of what Guido >> meant, I assumed he was saying "p can only have one scope in the >> synthetic function: local or non-local, not both, and local is what I >> propose". For example, let's flesh out his example a bit more: >> >> p

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Greg Ewing
Kirill Balunov wrote: While for those who are familiar with Pascal, Icon and other languages that use this syntax, this - `:=` looks natural. As someone familiar with Pascal, I think the similarity to the Pascal assignment operator is actually an argument *against* it. Knowing what it means

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Greg Ewing
Gustavo Carneiro wrote: IMHO, all these toy examples don't translate well to the real world because they tend to use very short variable names while in real world [good written code] tends to select longer more descriptive variable names. I don't believe that's always true. It depends on the

Re: [Python-ideas] A comprehension scope issue in PEP 572

2018-05-11 Thread Jacco van Dorp
>[Tim] > Since this is all about scope, while I'm not 100% sure of what Guido > meant, I assumed he was saying "p can only have one scope in the > synthetic function: local or non-local, not both, and local is what I > propose". For example, let's flesh out his example a bit more: > > p = 42

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Greg Ewing
Guido van Rossum wrote: I'd need well-reasoned explanations My reasoning is essentially the same as what I've already said about "where". To summarise, "given" sounds like something an English-speaking mathematician would write, whereas ":=" doesn't even have an obvious pronunciation. Some

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-11 Thread Greg Ewing
+1 given, -1 := -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: about the operator precedence of :=

2018-05-11 Thread Tim Peters
[Guido] > ,,, > OT about the name: despite Tim's relentless pushing of "binding expressions" > in the end I think they should be called "assignment expressions" just like > in C. Ha! I already gave up on "binding expressions". For nearly a full day, I've been rigidly calling them "binding