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

Mon Jan 1 23:03:56 CET 2007

To Tony and Kay, my short answer is: use __returns__ .

Moving to python-ideas as per Guido's request:

"Guido van Rossum" <guido at python.org> wrote:
> 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?
> > 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.

Certainly, but those two operators, and basically every other operator
used in Python have long-standing semantics in basically every language
that Python is even remotely related to.

> > 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.

I don't buy your "suggested semantic" argument.  And even if I did,
operator overloading allows people to choose the semantics of operations
for themselves; suggesting a semantic for an operation would be a set of
documentation that would never be read, and if it was read, ignored.

> > 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.

Ahh, but in this case there is precisely one place where the '->'
operator is planned on being found for Py3k:

    def <name>(<arglist with or without annotations>) -> <annotation>:
        <body>

In that sense, we don't need a fcn_obj.__becomes__(<annotation>) method,
and that wasn't what the discussion was about, it was "what should the
attribute be called for this already agreed upon *function annotation*?".

Now, because this *particular* annotation was created to allow for the
annotation of "returns", I agree with Kay's last suggestion, the
attribute should be called __returns__, as that is *exactly* what the
annotation was meant to convey.

> >  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.

Claiming "we want a particular operation to always refer to the same
method/attribute" is only applicable if a particular operation has a
chance of meaning more than one thing.  Currently it means *exactly* one
thing in the context of Python, 'this function returns X', so in my
opinion, your argument isn't applicable.

If you can manage to convince more people in python-ideas of arbitrary
operations (as per your previous message(s) on the subject), and/or you
can convince Guido to say "I would like more operations in Python", then
your argument is applicable.

However, I don't believe that you will be able to convince Guido that
the large set of operations that you have previously posted about would
be a good idea, and I certainly don't believe it would happen with
sufficient time to make it into the first Py3k release.

 - Josiah