[Python-ideas] PEP 572: about the operator precedence of := (Guido van Rossum)

Thu May 10 03:30:10 EDT 2018

>
> 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 <guido at python.org>
> To: Python-Ideas <python-ideas at python.org>
> Subject: [Python-ideas] PEP 572: about the operator precedence of :=
> Message-ID:
>         <
> CAP7+vJJSDeL0FWiYDhRfkgfxGX-oKKynfzyF3fHS+kkjb6DePA at 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.hettinger at gmail.com>
> To: Facundo Batista <facundobatista at gmail.com>
> Cc: Python-Ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Have a "j" format option for lists
> Message-ID: <67A74EA6-DA5B-492C-9811-F995EF90997A at gmail.com>
> Content-Type: text/plain;       charset=us-ascii
>
> On May 9, 2018, at 7:39 AM, Facundo Batista <facundobatista at 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 <rosuav at gmail.com>
> To: Python-Ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] PEP 572: about the operator precedence of
>         :=
> Message-ID:
>         <
> CAPTjJmrWHhmidGQ-H4FcBoJqrP69eVfkF2MBG1KYrh_W6adFKQ at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, May 10, 2018 at 1:33 PM, Guido van Rossum <guido at 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 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
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 138, Issue 65
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180510/c3e779e9/attachment-0001.html>