[Python-3000] Draft pre-PEP: function annotations
Phillip J. Eby
pje at telecommunity.com
Mon Aug 14 06:52:41 CEST 2006
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
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
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.)
More information about the Python-3000