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@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
