[Python-3000] Draft pre-PEP: function annotations

[Phillip J. Eby]

At 03:22 PM 8/14/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>>Since many people seem to be unfamiliar with overloaded functions, I 
>>would just like to take this opportunity to remind you that the actual 
>>overload mechanism is irrelevant.
>
>I don't think it's the concept of overloadable functions
>that people are having trouble with here, but that you
>haven't clearly explained *how* they would be applied
>to solving this particular problem.

In the same way that plain old standard Python duck typing would be 
used.  The only differences between overloaded functions and duck typing 
are that:

1. Overloaded functions can't accidentally collide, the way names chosen 
for duck typing can.

2. Third parties can declare overloaded methods without monkeypatching, but 
duck typing requires that you be the author of the object in question or 
that you be able to monkeypatch the type to add methods.

3. You can usually define some default behavior for an unrecognized type - 
as though you could add methods to the 'object' type.

4. Overloaded functions can dispatch on more than one type at the same 
time, or do other things, depending on their implementation.

Aside from these extra features of overloaded functions, there isn't much 
difference between overloading and duck typing; it's merely the difference 
between:

       someOb.quack()

and:

       quack(someOb)

So, if you can imagine handling annotations using duck typing and 
hasattr(), then you can imagine doing it with overloaded functions.  If you 
can't imagine using duck typing or hasattr() to process some annotations 
and ignore the ones you don't understand, then I don't really know how I 
would explain it.


>You seem to think the answer to that is so obvious
>that it doesn't need mentioning, but we're not all
>up to the same mental speed as you on this.
>
>Perhaps you could provide a complete worked-out
>example for people to look at?

I did - the PEAK documentation links I gave previously included a doctest 
that walked through the definition of a 'Message()' attribute annotation 
that prints a message at class definition (or other metadata definition) 
time.  The other two links showed examples of using attribute annotations 
for declaring security permissions and command-line options.

Some people said they didn't "get" anything from those links, but I'm at 
somewhat of a loss to understand why.  The examples there are very short 
and simple; in fact the complete Message implementation, including imports 
and overload declarations is only *6 lines long*.

So, my only guess is that the people who looked at that skimmed right past 
it, looking for something more complicated!  They probably then proceeded 
to the rest of the documentation and got bogged down in other aspects of 
the framework that aren't related to this discussion.

Therefore, if anybody would like to provide an example of how *they* would 
write code for some function attribute scenario, I'll happily modify it to 
demonstrate tell-don't-ask with either duck typing, adaptation, 
overloading, or whatever you like.  But from a communication POV, it 
doesn't make sense to me to try and write an example, since it's going to 
come from *my* worldview (in which this is a trivial problem) and not the 
worldview of the people who don't understand it.

It seems to me that the right way to proceed is to have somebody provide an 
example in *their* worldview, so that when I alter it they will have a 
reference point for what I'm talking about.  (Notice that this seemed to 
work well for Josiah and Paul when I reworked Paul's example.)