On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
