[Python-ideas] The @update operator for dictionaries

[Chris Angelico]

On Sun, Mar 10, 2019 at 4:22 AM Jonathan Fine <jfine2358 at gmail.com> wrote:
>
> Steven D'Aprano wrote
>
> > The last thing we're going to do is repeat Ruby's design mistake of
> > making code dependent on spaces around operators.
>
> I'd say that Ruby's mistake was encouraging programmers to write code
> that was hard for human beings to read accurately and quickly. As we
> say in Python, readability counts. And that's part of the PEP process.
>
> Let me clarify the additions to the grammar.
>
>    'foo' is a valid Python variable name
>    '@foo=' is to be a valid incremental assignment operator
>   '@foo' is to be a valid Python binary operator
>
> For clarity, we keep '@' and '@=' as binary and incremental assignment
> operators.
>
> The worst possible example of ambiguity and incompatibility is perhaps
>     a at b+1
> which is valid Python both before and after, but with different syntax
>     a @ (b + 1) # Before
>     a @b (+1)  # After

Actually, due to operator precedence, the current interpretation is:

(a @ b) + 1

That's a massive compatibility break. You're making it so the presence
of whitespace around an operator not just changes its precedence, but
actually changes "b" from a value to a token. There's a huge
difference between:

x.upper

and

x+upper

One of them looks up the name "upper" as an attribute of whatever
object 'x' is, and the other evaluates "upper" in the current context
(looking for a local or global variable, or a built-in). Atoms and
values are fundamentally different; you can replace a simple name with
an expression (since they're both values), but you can't do that with
an atom:

x+(dispatch["upper"]) # can do exactly the same thing as x+upper
x.(dispatch["upper"]) # SyntaxError

You're proposing to change the @ symbol from being like the first
example to being like the second... but ONLY if there's the right
pattern of whitespace.

I hope that this has 0% chance of happening.

You'll do better to pick some other symbol, such that you're giving
meaning to something that is currently an error. At least that way,
there won't be code that behaves drastically differently on 3.8 and
3.9.

ChrisA