[Python-ideas] [Python-3000] PEP 3107 Function Annotations: overloadable ->
jcarlson at uci.edu
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>:
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.
More information about the Python-ideas