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

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

Python-Dev mailing list

Reply via email to