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

[Phillip J. Eby]

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

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 
annotation types.

Providing good examples and recommending best practices is one thing, but 
mandating a particular semantics is another.