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
[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`
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
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
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
[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
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
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,
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
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
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
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
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
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
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
[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
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
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
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
>
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
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
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
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
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
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
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
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
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):
>
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
(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
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"
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
>[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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
[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
>[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
+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/
[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
61 matches
Mail list logo