> > 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 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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 138, Issue 65 > ********************************************* >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/