It's horrors like this: g(items[idx] := idx := f())
That make me maybe +0 if the PEP only allowed simple name targets, but decisively -1 for any assignment target in the current PEP. I would much rather never have to read awful constructs like that than get the minor convenience of: if (val := some_expensive_func()) > 0: x = call_something(val) On Fri, Apr 20, 2018, 3:39 PM Chris Angelico <ros...@gmail.com> wrote: > On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth > <christ...@grothesque.org> wrote: > > Chris Barker - NOAA Federal wrote: > > > >> > Personally, I even slightly prefer > >> > > >> > a := 3 > >> > > >> > to the commonplace > >> > > >> > a = 3 > >> > because it visually expresses the asymmetry of the operation. > >> > >> Careful here! That’s a fine argument for using := in a new language, > >> but people using := when they don’t need an expression because they > >> like the symbol better is a reason NOT to do this. > > > > Perhaps you are right and it is indeed unrealistic to expect people to > > (eventually) shift to using := for simple assignments after 28 years of > > Python... > > It's not just 28 years of Python. It's also that other languages use > "=" for assignment. While this is by no means a clinching argument, it > does have some weight; imagine if Python used "=" for comparison and > ":=" for assignment - anyone who works simultaneously with multiple > languages is going to constantly type the wrong operator. (I get this > often enough with comment characters, but my editor will usually tell > me straight away if I type "// blah" in Python, whereas it won't > always tell me that I used "x = 1" when I wanted one of the other > forms.) > > > One way or the other, I'd like to underline a point that I made > > yesterday: I believe that it's important for sanity that taking any > > existing assignment statement and replacing all occurrences of "=" by > > ":=" does not have any effect on the program. > > > > PEP 572 currently proposes to make ":=" a binary operator that is > > evaluated from right to left. > > This is one of the points that I was halfway through working on when I > finally gave up on working on a reference implementation for a > likely-doomed PEP. It might be possible to make := take an entire > sequence of assignables and then set them left to right; however, this > would be a lot more complicated, and I'm not even sure I want that > behaviour. I don't want to encourage people to replace all "=" with > ":=" just for the sake of it. The consistency is good if it can be > achieved, but you shouldn't actually DO that sort of thing normally. > > Consider: one of the important reasons to define the assignment order > is so you can reference a subscript and also use it. For instance: > > idx, items[idx] = new_idx, new_val > > But you don't need that with :=, because you can: > > items[idx := new_idx] = new_val > > (and you can use := for the second one if you wish). And actually, > this one wouldn't even change, because it's using tuple unpacking, not > the assignment order of chained assignments. I cannot think of any > situation where you'd want to write this: > > idx = items[idx] = f() > > inside an expression, and thus need to write it as: > > g(items[idx] := idx := f()) > > So I have no problem with a style guide saying "yeah just don't do > that", and the PEP saying "if you do this, the semantics won't be > absolutely identical to '='". Which it now does. > > Now, if someone else wants to work on the reference implementation, > they're welcome to create this feature and then see whether they like > it. But since I can't currently prove it's possible, I'm not going to > specify it in the PEP. > > ChrisA > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com