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

Mon Jan 1 23:25:22 CET 2007

Josiah Carlson wrote:
> 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

Sorry, I'm a habitual generalizer :)

Anyway, I'm not going to push on this one any further, neither here nor 
in python-ideas. There are more important things to work on.

-- Talin