[Python-3000] Draft pre-PEP: function annotations
Phillip J. Eby
pje at telecommunity.com
Sun Aug 13 04:23:00 CEST 2006
At 03:00 PM 8/12/2006 -0700, Talin <talin at acm.org> wrote:
>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."
And your point is what?
> 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.
You've lost me here entirely. If we didn't want unambiguous semantics,
we'd write programs in English, not Python. :)
>(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.)
Um, okay. I'm not sure what benefit this new term adds over "operation
that uses annotations", which is what I've been using, but whatever.
>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.
Um, what? Why are you adding all this complication to a simple idea?
Duck typing is normal, simple, standard Python programming practice. We
use objects with methods all the time, and check for the existence of
attributes all the time.
I don't understand why you insist on making that more complicated than it
is. It's really simple. Annotations are objects. Objects can be
inspected, or selected by type. You can do what you want to with them.
How complex is that?
(Meanwhile, I'm going to ignore all the red herrings about freedom and
commerce and other rigamarole that has absolutely nothing to do with
Going forward, may I suggest you take a look at Java and C# argument
annotations before continuing to pursue this spurious line of
reasoning? I'm curious to see what your explanation will be for why these
other languages doesn't have the problems that you claim will inevitably occur.
Meanwhile, if library authors write bad code because they don't understand
basic OO concepts like duck typing and "tell, don't ask", then their users
will educate them when they complain about not being able to use multiple
Providing good examples and recommending best practices is one thing, but
mandating a particular semantics is another.
More information about the Python-3000