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

[Guido van Rossum]

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/)