[Python-3000] PEP 3107 Function Annotations: overloadable ->

Mon Jan 1 22:20:04 CET 2007

This is sufficiently controversial that I believe it ought to go to
python-ideas first. If it comes to a PEP it should be a separate one
from PEP 3107.
On 1/1/07, Talin <talin at acm.org> wrote:
> 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
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)