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

Talin talin at acm.org
Sun Aug 13 00:00:45 CEST 2006

Phillip J. Eby wrote:

At 12:38 PM 8/12/2006 -0700, Paul Prescod wrote:

However, if you have:

def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) There is no ambiguity. Likewise: def cat( infile:opt("i") = sys.stdin, outfile:opt("o") = sys.stdout ): is unambiguous. And the interpetation of: def cat(infile: [doc("input stream"), opt("i")] = sys.stdin, outfile: [doc("output stream"), opt("o")] = sys.stdout ):

By doing this, you've already introduced an implicit requirement for annotations: Rather than saying that annotations can be "any format you want", the actual restriction is "any format you want that is distinguishable from other formats." More specifically, the rule is that annotations intended for different consumers must be distinguishable from each other via rule. This is in direct contradiction with the statement in the PEP that says that annotations have no predefined syntax or semantics -- they are required to have, at minimum, semantics sufficient to allow rule-based discrimination.

(BTW, I propose the term "Annotation Consumer" to mean a body of code that is intended to process annotations. You can have decorator-based consumers, as well as external consumers that are not part of the decorator stack and which inspect the function signature directly, without invoking the decorators.)

Lets use the term 'discriminator' to indicate any means, using function overloading or whatever, of determining which consumers should process which annotations. Lets also define the term 'discriminator protocol' to mean any input specifications to the discriminator - so in the above example, 'doc()' and 'opt()' are part of the discriminator protocol.

Now, you are trying very hard not to specify a standard discriminator protocol, but the fact is that if you don't do it, someone else will. Nobody wants to have to write their own discriminator for each application. And you can't mix discriminator protocols unless those protocols are a priori compatible.

Thus, there is very strong pressure to create a single, standard discriminator, or at least a standard discriminator protocol. The pressure is based on the fact that most users would rather deal with a protocol that someone else has written rather than writing their own. And because mixing protocols has the potential for discrimination errors, a heterogeneous environment with multiple protocols will inevitably degenerate into one where a single protocol has a monopoly.

So why don't you save us all the trouble and pain and just define the standard discrimination mechanism up front? As I have shown, its going to happen anyway - its inevitable - and delaying the decision simply means a lot of heartache for a lot of folk until the one true discriminator takes over. (Which is another thing that I was trying to illustrate with my SysEx story.)

As a footnote, I'd like to make a philosophical point about designing protocols. A 'protocol' (not in the technical sense, but in the sense of human relations) is simply an agreement to curtail the range of one's behavior to a restricted subset of what one is capable of, in order to facilitate cooperation between individuals. Language is a protocol - as I am typing this message, I implicitly agree to use words of English, rather than random made-up syllables, in order to facilitate understanding of my meaning.

Now, the curious and paradoxical thing about protocols is that in order to give the most freedom, you have to take some freedom away. Taking away certain freedoms can give you more freedom, because it allows you to predict and rely on the behaviors of the other participants in the protocol, enabling you to accomplish things that you wouldn't be able to do otherwise. For a given situation, there will be some "sweet spot", some balance between openness and restriction, that will give the largest amount of "effective" freedom and capability to the participants.

Here's an example: Cultures which have a strong mercantile ethic for fair dealing and enforcement of contracts tend to have vastly more efficient national economies. In countries where the mercantile ethic is poor, transaction costs are much higher - each individual has to spend effort vetting and enforcing each potential transaction, instead of being able to simply trust the other person. So by voluntarily restricting ones behavior to not unfairly take advantage of others and thus gain a temporary local advantage, one gains a huge advantage on the aggregate level.

For this reason, I am skeptical of the benefit of completely open-ended protocols. The value of the protocol is in the agreement between individuals - if the individuals don't agree on much, then there's not much value to be had.

-- Talin

More information about the Python-3000 mailing list