[Python-3000] Type annotations: annotating generators

[Jim Jewett]

On 5/19/06, Guido van Rossum <guido at python.org> wrote:

> The rest is just an exercise in attempting to come up with a pragmatic
> set of operators and conventions that some people might be using for
> talking about types. This is the idea of parameterizing types a la
> dict[str, int|str] (which I should point out is valid *syntax* today
> and can be made to execute correctly by modest additions to the type
> metaclass) and solving various other issues pragmatically, e.g.
> lambda:A for forward references and Funct(int, list[int]).returns(int)
> to describe signatures.

Today, int|str raises a TypeError.

If I didn't already know what you wanted, I would sort of expect it to
be the same as (int or str) which isn't helpful.

It sounds like what you want is that type.__or__ would magically
include the equivalent of not fully reducing the expression.  For
example, it might return a new instance of class TypeChecker with a
__call__ method that checks isinstance against each argument, unless
one argument is itself another TypeChecker instance, in which case it
would call that checker instead of doing an isinstance ...

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)):

or

(2)  Defining the complex predicate before using it

    def int_or_str(arg):
        return isinstance(arg, int) or isinstance(arg, str)

    def f(a:int_or_str)

-jJ