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 pattern-matching yesterday between
[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` i
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 emai
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 g
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 "=".
:=
> > 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
Python-ideas@python.org
[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 abou
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 dis
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, five
> > characters, l
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 Ti
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 that ":=" is slow to
>> disti
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 somethi
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 cases are not identi
'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
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 example), I
think readabilit
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 values
[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 appea
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 significant
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 th
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
> short of the maximum.
To
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 usefu
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 and understand that lin
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
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
[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.
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:
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 things up.
Indeed.
A though
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 I've already
> said about "where"
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 preferab
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 equal all-caps cee em de
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 do
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 to
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):
> cmd.do_something()
> )
>
>
But you ca
> On 2018 May 11 , at 7:37 a, 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 hand, but putting space above readability in a
>>>
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 currently legal synta
(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 expansion isn't quite accurate,
> and
> >
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" notation since
> > it's commonly writte
On Fri, May 11, 2018 at 11:34 PM, Rhodri James wrote:
> 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.
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 r
>[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 m
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 iterable
> expression):
>
>
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 hand, but putting space above readability in
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 programs
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 command
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
A
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 descriptive variable names.
>>
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 skewmorphism.
You are ass
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
> expression):
>
> def
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 binding semantics of "
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 argume
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 lo
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 believ
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 improve readability, w
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 "given".
>
> If we comp
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:
+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 wrote:
> G
[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
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
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 c
>[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
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 vari
61 matches
Mail list logo
