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

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