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

[Phillip J. Eby]

At 07:49 PM 8/12/2006 -0400, "Collin Winter" <collinw at gmail.com> wrote:
>What Josiah is hinting at -- and what Talin describes more explicitly
>-- is the problem of how exactly "chaining" annotation interpreters
>will work.

I'd prefer we not use the word "interpreters" to describe operations that 
use annotations.  It carries a lot of excess baggage.


>The case I've thought out the most completely is that of using
>decorators to analyse/utilise the annotations:
>
>1) Each decorator should be written with the assumption that it is the
>only decorator that will be applied to a given function (with respect
>to annotations).
>
>2) Chaining will be accomplished by maintaining this illusion for each
>decorator. For example, if our annotation-sharing convention is that
>annotations will be n-tuples (n == number of annotation-interpreting
>decorators), where t[i] is the annotation the i-th decorator should
>care about, the following chain() function will do the trick (a full
>demo script is attached):

I don't see the point of this.  A decorator should be responsible for 
manipulating the signature of its return value.  Meanwhile, the semantics 
for combining annotations should be defined by an overloaded function like 
"combineAnnotations(a1,a2)" that returns a new annotation.  There is no 
need to have a special chaining decorator.

May I suggest that you try using Guido's Py3K overloaded function 
prototype?  I expect you'll find that if you play around with it a bit, it 
will considerably simplify your view of what's required to do this.  It 
truly isn't necessary to predefine what an annotation is, or even any 
structural constraints on how they will be combined, since the user is able 
to define for any given type how such things will be handled.