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

Collin Winter collinw at gmail.com
Fri May 19 19:56:39 CEST 2006


On 5/19/06, Guido van Rossum <guido at python.org> 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


More information about the Python-3000 mailing list