[Python-ideas] The @update operator for dictionaries

[Jonathan Fine]

SUMMARY
Acknowledgement of an error, and clarification of behaviour of '@b' vs
'@ b'. I claim that once '@b' is accepted as an operator, the
behaviour is perfectly natural and obvious.

AN ERROR
In a previous post, I mispoke. I should have written
    a at b+1
is valid Python before and after, but with different syntax.
    (a @ b) + 1 # Before - operator is '@'.
    a @b (+1) # After - operator is '@b'.

Chris Angelico kindly pointed out that my Before value was wrong.
Thank you, Chris.

WHITE SPACE AND OPERATORS
Chris also correctly points that
    '@ b' is parses as the '@' operator followed by the identifier 'b'
    '@b' parses as above (BEFORE)
    '@b' parses as the '@b' operator (AFTER)

He then correctly says that in my proposal the lack of whitespace
after an operator can cause the operator to absorb a following
identifier.

However, something similar ALREADY happens in Python.
    >>> a = nota = True
    >>> not a
    False
    >>> nota
    True

Today, whenever a Python operator ends in a letter, and is followed by
an identifier, white space is or some other delimiter is required
between the two. Python, rightly, refuse to guess that 'notary' might
be 'not ary'.

Here is another example
    >>> e = note = None
    >>> e is not e
    False
    >>> e is note
    True

This is not quite what's happening with '@b'. With 'is not e' the
following identifier 'e' absorbs the 'not' from the operator to create
'note'.

And finally
    >>> False is not None
    True
    >>> False is (not None)
    False

The 'natural language' operators appear in
https://docs.python.org/3/reference/expressions.html#operator-precedence

In my suggestion, '@' consumes for as long it can, first a letter, and
then name characters. This is exactly the same as with 'a' or 'b'.

I think this is a problem, but not nearly so bad as Chris suggests.
Some people have argued that the proposed semantics for dict + dict
are natural and obvious, once the behaviour of Python elsewhere is
understood. I claim the same for '@b' and '@ b', once we allow '@b' as
an operator (which was the whole purpose of the proposal.

By the way, it's likely that most users won't know that '@' by itself
is an operator, until they come to use matrices.

-- 
Jonathan