[Python-3000] PEP 3107 Function Annotations: overloadable ->
Talin
talin at acm.org
Mon Jan 1 22:11:59 CET 2007
Tony Lownds wrote:
>> From: Tony Lownds <tony at pagedna.com>
> What do people here think?
I've been wanting something like this, however the name I wanted to use
was "__becomes__" and "__rbecomes__". My reasoning is as follows:
1) Normally, we don't name operators based on their shape - we don't
call '/' the __slash__ operator, for example, nor do we call '|' the
"__vbar__" operator.
2) I think that all operators should have a "suggested semantic". When
someone overloads the '+' operator, its a good bet that the meaning of
the overload has something to do with addition or accumulation in a
general sense. This won't *always* be true, but it will be true often
enough.
But an arbitrary operator with no guidelines as to what it means is
anyone's guess; It means that when we see a '->' operator embedded in
the code, we have no idea what is being said.
From an HCI perspective, punctuation symbols improve code readability
only if their meanings are familiar to the reader; An operator whose
meaning is constantly changing is a hindrance to readability rather than
a help.
(This is why, although I have lobbied for new operators in the past, I
have lobbied against a generic operator declaration system a la Logix.
This was recently discussed on the python-ideas list.)
3) I suggest that the expression:
a -> b
should be read as:
"a becomes b"
which is why I propose the name "becomes". (An alternative is
"produces", but that's longer.)
-- Talin
More information about the Python-3000
mailing list