[Python-3000] Type annotations: annotating generators

[Jim Jewett]

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:

> > I think trying to put compound types directly into the signature may
> > require a little too much magic, compared to either:

> > (1)  Just use a tuple, and put the smarts in your decorator if you
> > need to actually do something with the information.

> >     @decorator_which_handles_tuples
> >     def f(a: (int, str)):

> How do you differentiate between this and wanting to assert that 'a'
> is a 2-tuple with a first element of type int and a second element of
> type str?

The decorator knows.  The human only knows by convention.  (But that's
true anyhow; a sneaky decorator could replace the entire function with
something having an unrelated signature.)

I expect that there would be other decorators using a tuple to say
"must meet all", rather than "must meet at least one".

>From my perspective, I figure ~80% of code won't even have annotations.
~80% of the rest won't need to combine them.
The "any" and "all" cases still only cover ~80% of the remainder .
(~3% of code)

That isn't enough to justify a special case.

I would expect more value (but still perhaps not enough) from
special-casing any of the following:

    annotation represents the (concrete) type
        arg:annotation <==> isinstance(arg, annotation)

    annotation represents a predicate (such as "implements this interface")
        arg:annotation <==> bool(annotation(arg)) is True

    annotation represents an adapter ("*make* it implement this interface")
        arg:annotation  ==> [wrapper replaces arg with] annotation(arg)


-jJ