[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