[Python-ideas] The @update operator for dictionaries

Jonathan Fine jfine2358 at gmail.com
Sat Mar 9 12:15:23 EST 2019


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

To return to Steve's point. A natural example of code using the
extended '@' syntax, which is hard to read accurately and quickly,
would probably be fatal to this suggestion.

Finally, in the discussion of the '@' operator (which Steve was part
of), the point was made many times that using the '@' operator made
the matrix code easier to read and understand. This was a major force
in the proposal. A major reason for this was its alignment with
standard mathematical notation.
https://mail.python.org/pipermail/python-ideas/2014-March/027053.html

I'm suggesting that the grammar allow us, if we wish, to write
   c = a @cup b
for the union of two sets. And
   len(A @cup B) == len(A) + len(B) - len(A @cap B)
is the very useful
https://en.wikipedia.org/wiki/Inclusion%E2%80%93exclusion_principle

Here, 'cup' and 'cap' are the visual names for the union and
intersection operators for sets.

-- 
Jonathan


More information about the Python-ideas mailing list