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

[Brice Parent]

Le 10/05/2018 à 09:32, Terry Reedy a écrit :

On 5/9/2018 11:33 PM, Guido van Rossum wrote:

I now think that the best way out is to rule `:=` in the top level 
expression of an expression statement completely 


I would like to be able to interactively enter

>>> a: = f(2,4)

to have 'a' echoed as well as bound.


This behaviour is reachable by using:

print(a := f(2,4))

Otherwise, I can see coming a new wave of devs saying assignment with 
"=" is outdated, and we should use the new assignment operator ":=". 
Cleaning code by removing useless prints is something, having to go 
through the syntax to remove the ":" of some ":=", and having to test 
everything again to be sure we didn't break anything is another matter 
(long live unit tests! But still...).


Side note: I wouldn't recommand to use `print(a := f(2,4))` either, as 
it would be a print-with-a-side-effect. Which would then also break the 
code if removed the usual way by deleting the line (or commenting it if 
you like messy). Maybe, for another proposal of course, we could allow 
the shell to be more verbose, by printing any explicit assignment 
(whether we used "=" or ":=" wouldn't matter)?


-Brice
___
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 :=

[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 useful to be able to use x := expression 
in the interactive interpreter to see the value immediately.

But I'd rather start off by prohibiting := as a stand-alone statement, 
and relax the restriction later, than by allowing it and then regretting 
it later.

I think the rule "binding expressions are prohibited as a stand-alone 
statement" might reduce some of the anxiety about having two ways to do 
assignment, even if the cost is that they are treated as a special case. 
(All other expressions are allowed as statements, even if they're 
pointless.)



-- 
Steve
___
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 :=

[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 operators" instead.
That's why everyone has warmed up to them so dramatically since
yesterday.

Oh.  They haven't?  Oh well - since verbal misdirection failed, I'll
go back to "assignment expressions'.  Chris always liked that better
anyway too.
___
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 :=

[Greg Ewing]

Tim Peters wrote:

Umm ... that's the opposite of what the Reference Manual says "lower":means:

"""
6.16. Operator precedence

The following table summarizes the operator precedence in Python, from
lowest precedence (least binding) to highest precedence (most
binding).
"""


Which is also in accord with the usual English meaning of the word
"precedence" -- things with higher precedence get done first.

--
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 :=

[Terry Reedy]

On 5/10/2018 9:53 AM, Guido van Rossum wrote:
On Thu, May 10, 2018 at 3:32 AM, Terry Reedy 
> wrote:


On 5/9/2018 11:33 PM, Guido van Rossum wrote:

I now think that the best way out is to rule `:=` in the top
level expression of an expression statement completely


I would like to be able to interactively enter

 >>> a: = f(2,4)

to have 'a' echoed as well as bound.


I hope that's a typo (the can be no space between `:` and `=`, since 
`:=` is a single token, just like `<=').


a := f(2,4) # corrected ;-)

We *could* make this work while still ruling out the ambiguous cases 
(which involve top-level commas on either side of the assignment 
expression).


OTOH I worry that this particular feature would cause `:=` to become 
part of many a teacher's bag of tricks to show off,


until someone tries a := [0]*1000


exposing users to it way too early for any curriculum, > and it might then 
elicit complaints that


def f():

... a := 5
...

f()



doesn't print `5`.


Although the reason the same as for any expression, I can believe that 
people will see it as different.  A bare assignment expression *looks* 
like a statement in a way that other expressions do not.
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.


--
Terry Jan Reedy


___
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 :=

[Paul Moore]

On 10 May 2018 at 17:38, Ethan Furman  wrote:
> On 05/10/2018 09:29 AM, M.-A. Lemburg wrote:
>>
>> On 10.05.2018 15:57, Guido van Rossum wrote:
>>>
>>> On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote:
>
>
 To a (former Pascal) programmer, a := 1 doesn't read like an
 operator. It's an assignment expression. If embedded expressions
 is where Python is heading, it should be made very clear where
 the embedded expression starts and where it ends on a line.

>>>
>>> The rules we've arrived at are about as straightforward as it gets: the
>>> RHS
>>> of `:=` ends at the nearest comma or close parenthesis/bracket/brace.
>>
>>
>> That may be easy for a computer to parse, but it's not for
>> a programmer. It would be better to contain such expressions
>> inside a safe container which is clearly visible to a human
>> eye.
>>
>> ohoh = a := (1, 2, 3), 4, a * 2
>
>
> I have no problem reading that.
>
>> vs.
>>
>> aha  = ((a := (1, 2, 3)), 4, a * 2)
>
>
> The extra parens are unneeded line noise (at least for me).

I found the version with extra parens *harder* to read. Although I
will admit neither is particularly easy to read (not surprising as
it's an artificial example intended to prove a point, not a real world
use case) and in practice I'd write

a = 1, 2, 3
ohoh = a, 4, a * 2

Look ma, no parens!

Paul
___
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 :=

[Ethan Furman]

On 05/10/2018 09:29 AM, M.-A. Lemburg wrote:

On 10.05.2018 15:57, Guido van Rossum wrote:

On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote:



To a (former Pascal) programmer, a := 1 doesn't read like an
operator. It's an assignment expression. If embedded expressions
is where Python is heading, it should be made very clear where
the embedded expression starts and where it ends on a line.



The rules we've arrived at are about as straightforward as it gets: the RHS
of `:=` ends at the nearest comma or close parenthesis/bracket/brace.


That may be easy for a computer to parse, but it's not for
a programmer. It would be better to contain such expressions
inside a safe container which is clearly visible to a human
eye.

ohoh = a := (1, 2, 3), 4, a * 2


I have no problem reading that.


vs.

aha  = ((a := (1, 2, 3)), 4, a * 2)


The extra parens are unneeded line noise (at least for me).

--
~Ethan~
___
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 :=

[M.-A. Lemburg]

On 10.05.2018 15:57, Guido van Rossum wrote:
> On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg  wrote:
> 
>> To a (former Pascal) programmer, a := 1 doesn't read like an
>> operator. It's an assignment expression. If embedded expressions
>> is where Python is heading, it should be made very clear where
>> the embedded expression starts and where it ends on a line.
>>
> 
> The rules we've arrived at are about as straightforward as it gets: the RHS
> of `:=` ends at the nearest comma or close parenthesis/bracket/brace.

That may be easy for a computer to parse, but it's not for
a programmer. It would be better to contain such expressions
inside a safe container which is clearly visible to a human
eye.

ohoh = a := (1, 2, 3), 4, a * 2

vs.

aha  = ((a := (1, 2, 3)), 4, a * 2)

You'd simplify the above logic to: the RHS of ":=" ends at the
nearest closing parenthesis.

> 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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 10 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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 :=

[Guido van Rossum]

On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg  wrote:

> To a (former Pascal) programmer, a := 1 doesn't read like an
> operator. It's an assignment expression. If embedded expressions
> is where Python is heading, it should be made very clear where
> the embedded expression starts and where it ends on a line.
>

The rules we've arrived at are about as straightforward as it gets: the RHS
of `:=` ends at the nearest comma or close parenthesis/bracket/brace.

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.

-- 
--Guido van Rossum (python.org/~guido)
___
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 :=

[Guido van Rossum]

On Thu, May 10, 2018 at 3:32 AM, Terry Reedy  wrote:

> On 5/9/2018 11:33 PM, Guido van Rossum wrote:
>
> I now think that the best way out is to rule `:=` in the top level
>> expression of an expression statement completely
>>
>
> I would like to be able to interactively enter
>
> >>> a: = f(2,4)
>
> to have 'a' echoed as well as bound.
>

I hope that's a typo (the can be no space between `:` and `=`, since `:=`
is a single token, just like `<=').

We *could* make this work while still ruling out the ambiguous cases (which
involve top-level commas on either side of the assignment expression).

OTOH I worry that this particular feature would cause `:=` to become part
of many a teacher's bag of tricks to show off, exposing users to it way too
early for any curriculum, and it might then elicit complaints that

>>> def f():
... a := 5
...
>>> f()
>>>

doesn't print `5`.

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.

-- 
--Guido van Rossum (python.org/~guido)
___
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 :=

[Nick Coghlan]

On 10 May 2018 at 13:33, Guido van Rossum  wrote:

> (I vaguely recall this has been brought up before, but I'm too lazy to
> find the subtread. So it goes.)
>
> PEP 572 currently seems to specify that when used in expressions, the
> precedence of `:=` is lower (i.e. it binds more tightly) than all operators
> except for the comma. I derive this from the single example `stuff = [[y :=
> f(x), x/y] for x in range(5)]`.
>
> From this it would follow that `f(a := 1, a)` is equivalent to `a = 1;
> f(1, 1)`, and also that `(a := 1, a)` is equivalent to `a = 1; (1, 1)`.
> (Although M.A.L. objected to this.)
>
> But what should `a := 1, 1` at the top level (as a statement) do? On the
> one hand, analogy with the above suggest that it is equivalent to `a = 1;
> (1, 1)`. But on the other hand, it would be really strange if the following
> two lines had different meanings:
>
> a = 1, 1   # a = (1, 1)
> a := 1, 1  # a = 1; (1, 1)
>
> I now think that the best way out is to rule `:=` in the top level
> expression of an expression statement completely (it would still be okay
> inside parentheses, where it would bind tighter than comma).
>

FWIW, this is one of the ambiguities that the generalised postfix
expression form of the given clause would reduce fairly significantly by
separating the result expression from the bound expression:

a = 1, 1
a given a = 1, 1 # As above, but also returns a
a = 1, x, 3 given x = 2

They also compose fairly nicely as an essentially right associative
operator:

a given a = 1, x, 3 given x = 2
a given a = (1, x, 3 given x = 2) # Same as previous
(a given a = 1), x, 3 given x = 2 # Forcing left-associativity

While you do have to repeat the bound name at least once, you gain a much
clearer order of execution (while it's an order of execution that's
right-to-left rather than left-to-right, "rightmost expression first" is
the normal way assignments get evaluated anyway).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 :=

[David Mertz]

On Wed, May 9, 2018, 11:53 PM Guido van Rossum  wrote:

> Oh, I hadn't even though of combining the two in one statement. That
> example is truly horrible (on first skim I didn't even notice it used two
> different assignment operators!) and strengthens my confidence that we
> should just disallow an un-parenthesized `:=` operator at the top level,
> where now the top level includes the RHS of a classic assignment.
>

IMO, I would strongly prefer calling an unparenthesized top-level ':=' a
SyntaxError.

>
___
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 :=

[Chris Angelico]

On Thu, May 10, 2018 at 7:04 PM, M.-A. Lemburg  wrote:
> Not sure whether this was discussed before (I'm not really
> following the discussion), but what happens if you write:
>
> check = 0 and (a := 1)
>
> ? Will "a" get assigned or not ?

No, it won't. It's the same as any other side effects after an 'and' -
that expression is completely not evaluated.

ChrisA
___
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 :=

[M.-A. Lemburg]

On 10.05.2018 05:52, Guido van Rossum wrote:
>> I would have := bind more tightly than the comma. Consider:
>>
>> a = 1, x := 2, 3
>>
>> IMO the only sane interpretation is "x = 2; a = 1, 2, 3". Effectively,
>> the := operator does not like to play with commas; we've already ruled
>> out "a, b := range(2)" as a means of unpacking, so it makes more sense
>> to have that simply mean "b = range(2); a, b".
>>
> 
> Oh, I hadn't even though of combining the two in one statement. That
> example is truly horrible (on first skim I didn't even notice it used two
> different assignment operators!) and strengthens my confidence that we
> should just disallow an un-parenthesized `:=` operator at the top level,
> where now the top level includes the RHS of a classic assignment.

Yes, please, and ideally not only at the top level, but
everywhere.

To a (former Pascal) programmer, a := 1 doesn't read like an
operator. It's an assignment expression. If embedded expressions
is where Python is heading, it should be made very clear where
the embedded expression starts and where it ends on a line.

Anything else will just result in hard to debug code with
subtle errors...

oops = 1, a := 2 * 3, 4, 5 - 6

By having to write:

ahhh = 1, (a := 2) * 3, 4, 5 - 6

you at least know that "(a := 2)" will evaluate to 2 in the
tuple on the right side.

Not sure whether this was discussed before (I'm not really
following the discussion), but what happens if you write:

check = 0 and (a := 1)

? Will "a" get assigned or not ?


All that said, I sometimes do wonder what people dislike
so much about explicit for-loops which make all of these
things obvious even to a complete Python newbie reading
the code.

IMO, line noise is not something Python should strive for.
Other languages such as APL are much better at that - just
look at the beauty of "(~R∊R∘.×R)/R←1↓ιR" ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 10 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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 :=

[Terry Reedy]

On 5/9/2018 11:33 PM, Guido van Rossum wrote:

I now think that the best way out is to rule `:=` in the top level 
expression of an expression statement completely 


I would like to be able to interactively enter

>>> a: = f(2,4)

to have 'a' echoed as well as bound.

--
Terry Jan Reedy

___
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 := (Guido van Rossum)

[Angus Hollands]

>
> Is there a more appropriate mechanism to showing support for a 'EXPR given
x = EXPR' approach, as suggested by Nick Coghlan? Then, keeping the binding
rules the same for statement assign, requiring parenthesis, would keep
things consistent. I personally prefer it to := for the reasons I mentioned
previously.
Angus Hollands

Message: 4
> Date: Wed, 9 May 2018 20:33:05 -0700
> From: Guido van Rossum <gu...@python.org>
> To: Python-Ideas <python-ideas@python.org>
> Subject: [Python-ideas] PEP 572: about the operator precedence of :=
> Message-ID:
> <
> cap7+vjjsdel0fwiydhrfkgfxgx-okkynfzyf3fhs+kkjb6d...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> (I vaguely recall this has been brought up before, but I'm too lazy to find
> the subtread. So it goes.)
>
> PEP 572 currently seems to specify that when used in expressions, the
> precedence of `:=` is lower (i.e. it binds more tightly) than all operators
> except for the comma. I derive this from the single example `stuff = [[y :=
> f(x), x/y] for x in range(5)]`.
>
> >From this it would follow that `f(a := 1, a)` is equivalent to `a = 1;
> f(1,
> 1)`, and also that `(a := 1, a)` is equivalent to `a = 1; (1, 1)`.
> (Although M.A.L. objected to this.)
>
> But what should `a := 1, 1` at the top level (as a statement) do? On the
> one hand, analogy with the above suggest that it is equivalent to `a = 1;
> (1, 1)`. But on the other hand, it would be really strange if the following
> two lines had different meanings:
>
> a = 1, 1   # a = (1, 1)
> a := 1, 1  # a = 1; (1, 1)
>
> I now think that the best way out is to rule `:=` in the top level
> expression of an expression statement completely (it would still be okay
> inside parentheses, where it would bind tighter than comma).
>
> An alternative would be to make `:=` bind less tight than comma (like `=`)
> everywhere, so that `a := 1, 1` indeed meant the same as `a = 1, 1`. But
> that feels very wrong at least for the case `f(a := 1, 1)` -- I believe Tim
> already mentioned that we've been conditioned by keyword arguments to parse
> this as `f((a := 1), 1)`. (I could add to this that we have done various
> things to generator expression syntax to avoid ever having to deal with
> ambiguities like `a, a+1 for a in range(10)` or `a for a in x, y`.)
>
> Another alternative would be to always require parentheses around `:=`, so
> that we would have to write `f((a := 1), 1)`. That's unambiguous, but
> otherwise just gets on the nerves.
>
> --
> --Guido van Rossum (python.org/~guido)
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/python-ideas/attachments/20180509/41b36ded/attachment-0001.html
> >
>
> --
>
> Message: 5
> Date: Wed, 9 May 2018 22:35:05 -0500
> From: Raymond Hettinger <raymond.hettin...@gmail.com>
> To: Facundo Batista <facundobati...@gmail.com>
> Cc: Python-Ideas <python-ideas@python.org>
> Subject: Re: [Python-ideas] Have a "j" format option for lists
> Message-ID: <67a74ea6-da5b-492c-9811-f995ef909...@gmail.com>
> Content-Type: text/plain;   charset=us-ascii
>
> On May 9, 2018, at 7:39 AM, Facundo Batista <facundobati...@gmail.com>
> wrote:
> >
> > This way, I could do:
> >
> >>>> authors = ["John", "Mary", "Estela"]
> >>>> "Authors: {:, j}".format(authors)
> > 'Authors: John, Mary, Estela'
> >
> ...
> >
> > What do you think?
>
> That is an inspired idea.  I like it :-)
>
>
> Raymond
>
>
>
>
> --
>
> Message: 6
> Date: Thu, 10 May 2018 13:42:05 +1000
> From: Chris Angelico <ros...@gmail.com>
> To: Python-Ideas <python-ideas@python.org>
> Subject: Re: [Python-ideas] PEP 572: about the operator precedence of
> :=
> Message-ID:
> <
> captjjmrwhhmidgq-h4fcbojqrp69evfkf2mbg1kyrh_w6ad...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, May 10, 2018 at 1:33 PM, Guido van Rossum <gu...@python.org>
> wrote:
> > (I vaguely recall this has been brought up before, but I'm too lazy to
> find
> > the subtread. So it goes.)
> >
> > PEP 572 currently seems to specify that when used in expressions, the
> > precedence of `:=` is lower (i.e. it binds more tightly) than all
> operators
> > except for the comma. I derive this from the single example `stuff = [[y
> :=
> > f(x), x/y] for x in range(5)]`.
> >
> > From this it would follow that `f(a := 1, a)` is 

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

[Tim Peters]

[Guido]
> (I vaguely recall this has been brought up before, but I'm too lazy to find
> the subtread. So it goes.)
>
> PEP 572 currently seems to specify that when used in expressions, the
> precedence of `:=` is lower (i.e. it binds more tightly)

Umm ... that's the opposite of what the Reference Manual says "lower":means:

"""
6.16. Operator precedence

The following table summarizes the operator precedence in Python, from
lowest precedence (least binding) to highest precedence (most
binding).
"""


> than all operators except for the comma.

Which gets more potentially confusing become the comma isn't listed at
all as "an operator".   Instead the meaning of commas for building
tuples is captured by the higher-level `expression-list` grammar
production:

expression_list ::=  expression ( "," expression )* [","]

So _every_ mere operator "binds more tightly" (if you view it in those
terms) than a comma in an expression list.

What was mostly discussed before - after giving up on fully generally
"assignment expressions" - was whether ":=" should get a precedence
between comparison and bitwise OR operators.  So that, e.g., parens
wouldn't be needed in

if x := match() is not None:

to get the intended

if (x := match()) is not None:

But that never gained much traction, and it was dropped quickly.  It
was left with a (possibly unwritten!) consensus that ":=" should bind
very weakly as an operator.  Of the binary infix operators, the most
weakly binding (the weakest of which now is Boolean OR).


> I derive this from the single example
> `stuff = [[y := f(x), x/y] for x in range(5)]`.`

As above, the part you're looking at there falls under the
expression_list part of the grammar, and no binary operator could
group as

y OP (f(x), x/y)

instead.  All binary operators group as

(y OP f(x)), (x/y)


> From this it would follow that `f(a := 1, a)`

And now you're throwing in the entirely different meaning of commas in
argument lists ;-)  But same thing:  no operator can cross comma
boundaries in argument lists, because the grammar  of argument lists
doesn't allow for that either.  Even; e.g.,

f(lambda x: x, 2)

groups as

f((lambda x: x), 2)


> is equivalent to `a = 1; f(1, 1)`,

Yup.

> and also that `(a := 1, a)` is equivalent to `a = 1; (1, 1)`. (Although
> M.A.L. objected to this.)

That's just another instance of expression_list.

Nothing so far has surprised me, because I have been viewing ":=" as
an operator for some time now.


> But what should `a := 1, 1` at the top level (as a statement) do? On the one
> hand, analogy with the above suggest that it is equivalent to
>`a = 1; (1, 1)`.

If it's an operator, there's really no choice about that.


> But on the other hand, it would be really strange if the following two
> lines had different meanings:
>
> a = 1, 1   # a = (1, 1)
> a := 1, 1  # a = 1; (1, 1)

Agreed.


> I now think that the best way out is to rule `:=` in the top level
> expression of an expression statement completely (it would still be okay
> inside parentheses, where it would bind tighter than comma).

Probably prudent, and no objections here.


> An alternative would be to make `:=` bind less tight than comma (like `=`)
> everywhere, so that `a := 1, 1` indeed meant the same as `a = 1, 1`. But
> that feels very wrong at least for the case `f(a := 1, 1)` -- I believe Tim
> already mentioned that we've been conditioned by keyword arguments to parse
> this as `f((a := 1), 1)`. (I could add to this that we have done various
> things to generator expression syntax to avoid ever having to deal with
> ambiguities like `a, a+1 for a in range(10)` or `a for a in x, y`.)

Offhand, since comma is not formally "an operator" now, I expect it
would require major surgery to the grammar to have

a := 1, 1

group as

a := (1, 1)

in any context.  At least if ";=" is treated as "just another
operator" and doesn't grow its own unique-to-it pile of grammar rules.


> Another alternative would be to always require parentheses around `:=`, so
> that we would have to write `f((a := 1), 1)`. That's unambiguous, but
> otherwise just gets on the nerves.

I hoped that rigidly calling these "binding expressions" would break
the connection in peoples' minds that these somehow "should behave"
like assignment statements, but that seems futile.  There's really
nothing surprising here _if_ it's viewed as just another operator.
Nobody would be tempted to, e.g., add parens to f(a + 1, 1), or if `+`
were any other binary operator either.  So, over time, it would be
just as annoying need to type them for the `:=` operator.
___
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 :=

[Guido van Rossum]

On Wed, May 9, 2018 at 8:42 PM, Chris Angelico  wrote:

> On Thu, May 10, 2018 at 1:33 PM, Guido van Rossum 
> wrote:
> > (I vaguely recall this has been brought up before, but I'm too lazy to
> find
> > the subtread. So it goes.)
> >
> > PEP 572 currently seems to specify that when used in expressions, the
> > precedence of `:=` is lower (i.e. it binds more tightly) than all
> operators
> > except for the comma. I derive this from the single example `stuff = [[y
> :=
> > f(x), x/y] for x in range(5)]`.
> >
> > From this it would follow that `f(a := 1, a)` is equivalent to `a = 1;
> f(1,
> > 1)`, and also that `(a := 1, a)` is equivalent to `a = 1; (1, 1)`.
> (Although
> > M.A.L. objected to this.)
> >
> > But what should `a := 1, 1` at the top level (as a statement) do? On the
> one
> > hand, analogy with the above suggest that it is equivalent to `a = 1; (1,
> > 1)`. But on the other hand, it would be really strange if the following
> two
> > lines had different meanings:
> >
> > a = 1, 1   # a = (1, 1)
> > a := 1, 1  # a = 1; (1, 1)
> >
> > I now think that the best way out is to rule `:=` in the top level
> > expression of an expression statement completely (it would still be okay
> > inside parentheses, where it would bind tighter than comma).
>
> I would have := bind more tightly than the comma. Consider:
>
> a = 1, x := 2, 3
>
> IMO the only sane interpretation is "x = 2; a = 1, 2, 3". Effectively,
> the := operator does not like to play with commas; we've already ruled
> out "a, b := range(2)" as a means of unpacking, so it makes more sense
> to have that simply mean "b = range(2); a, b".
>

Oh, I hadn't even though of combining the two in one statement. That
example is truly horrible (on first skim I didn't even notice it used two
different assignment operators!) and strengthens my confidence that we
should just disallow an un-parenthesized `:=` operator at the top level,
where now the top level includes the RHS of a classic assignment.

-- 
--Guido van Rossum (python.org/~guido)
___
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 :=

[Chris Angelico]

On Thu, May 10, 2018 at 1:33 PM, Guido van Rossum  wrote:
> (I vaguely recall this has been brought up before, but I'm too lazy to find
> the subtread. So it goes.)
>
> PEP 572 currently seems to specify that when used in expressions, the
> precedence of `:=` is lower (i.e. it binds more tightly) than all operators
> except for the comma. I derive this from the single example `stuff = [[y :=
> f(x), x/y] for x in range(5)]`.
>
> From this it would follow that `f(a := 1, a)` is equivalent to `a = 1; f(1,
> 1)`, and also that `(a := 1, a)` is equivalent to `a = 1; (1, 1)`. (Although
> M.A.L. objected to this.)
>
> But what should `a := 1, 1` at the top level (as a statement) do? On the one
> hand, analogy with the above suggest that it is equivalent to `a = 1; (1,
> 1)`. But on the other hand, it would be really strange if the following two
> lines had different meanings:
>
> a = 1, 1   # a = (1, 1)
> a := 1, 1  # a = 1; (1, 1)
>
> I now think that the best way out is to rule `:=` in the top level
> expression of an expression statement completely (it would still be okay
> inside parentheses, where it would bind tighter than comma).

I would have := bind more tightly than the comma. Consider:

a = 1, x := 2, 3

IMO the only sane interpretation is "x = 2; a = 1, 2, 3". Effectively,
the := operator does not like to play with commas; we've already ruled
out "a, b := range(2)" as a means of unpacking, so it makes more sense
to have that simply mean "b = range(2); a, b".

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/