[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