[Python-3000] Type parameterization (was: Re: Type annotations: annotating generators)

[Collin Winter]

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> That's not quite how I did it. list[int] should return another type,
> not a list instance. Here's a minimal example of what I'm after (truly
> minimal because it only allows a single parameter named T):

[snip]

I agree that the act of parameterizing dict, list, tuple, set, etc
will end up returning instances of other types, but I'd like to save
that particular discussion for later. For now, what do you think of
the underlying idea of having bracket-based parameterization be
redirected a call to some double-underscore method (as I outlined
earlier)?

I'm trying to give as much flexibility as possible to the annotation
classes. While simply assigning the parameter to an attribute of the
new annotation object (here, "newcls.T = arg") works for simple
examples, I can easily think of cases where the annotation class
(here, "List") would want to do its own processing:

1. Classes implementing boolean type expressions (Or, And, Not, Xor,
etc) might want to try and simplify the expression: Or(int, Or(int,
float)) simplifies to Or(int, float); And(Not(int), Not(float))
becomes Not(Or(int, float)); etc.

2. Similarly, annotation classes might want to do more complex
parameter validation. Or(), for instance, might want to assert that it
needs at least two distinct parameters (that is, Or(int, int, int)
simplifies to Or(int), which makes no sense and is an error).


The reason for putting parameterization into its own double-underscore
method is to make it easier to for people to incorporate their own
classes into the type system. Rather than playing metaclass tricks or
writing a separate class to handle parameterized typechecking, you can
use the same class name in type expressions as you do in "real" code:
constructing a BinaryTree instance might look like BinaryTree(5, 6) in
code, and asserting that it contains only ints would look like
BinaryTree[int]. To add parameterizability to BinaryTree, all you'd
have to do is define an appropriate __parameterize__ method.

Not being able to reuse the BinaryTree class like this leads to things
like CheckBinaryTree(int) or something equally unpleasant.

Collin Winter