[Python-3000] Type annotations: annotating generators (original) (raw)

Jim Jewett jimjjewett at gmail.com
Fri May 19 21:06:38 CEST 2006

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

More information about the Python-3000 mailing list