[Python-3000] Draft pre-PEP: function annotations (original) (raw)

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

More information about the Python-3000 mailing list