On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > It feels a little too general for my taste. Have you written a bunch > of those __parameterize__ functions yet?
Some, yes: 1. There's an example of a typecheck-able binary tree in typecheck's tests/test_examples [1] that supports parameterization. 2. Though they might not be a great idea, I've implemented patterned lists as a proof-of-concept before. It will ship with the next version of typecheck as an example. > I somehow feel that the metaclass might want to work a little harder so that > the > parameterizable class only has to specify what's unique to it. For > example (not sure this is the right API) I could imagine that a > parameterizable class should only have to do the following: > > class List(list): > __metaclass__ = ParameterizableClass > __parameters__ = ["T"] > > List[X] would then return a new class C for which C.T is X. [snip] > I think this may be odd enough that subclassing the metaclass would be > more appropriate. [snip] > But we need code before we can continue this discussion; I > don't immediately how you get from this argument to making each class > implement its own __parameterize__() method. I don't want each class to implement its own __parameterize__() method. To me, the easiest thing to do would be easier to have the built-in types inherit a __parameterize__() method that handles a common behaviour (like what you've laid out). User-defined classes would then override it as they saw fit. Under your suggestion, users would have to subclass the appropriate metaclass, override some portion of the metaclass's behaviour, then link their annotation classes to this new metaclass. This seems like a lot of extra work. [pauses, thinks about this for an hour or so] However, you've managed to somewhat derail my conviction that this extra work would be an overly-taxing burden. The main use I see for overriding __parameterize__() is to validate the parameters, which I'm having trouble finding useful use cases for. Every example I come up with -- including the two at the top of this post -- can be reduced to your <type>.T idea. I'm going to do a branch of typecheck to play around with this parameterization syntax; I'll let you know how it goes. Collin Winter [1] - http://tinyurl.com/n2v3b _______________________________________________ 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
