On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > I'd like to see the typechecking machinery ignore differences like > > "real type" v "pseudo type", looking only at whether, zB, a > > __parameterize__ method is present. Using __parameterize__ method (or > > some other name) allows maximum flexibility with respect to type > > parameterization. > > > > For example, the built-in list type might not allow the patterned > > parameterization I asked about above. A user might choose to subclass > > list to provide this, giving the subclass a __parameterize__ method > > something like: > > > > @classmethod > > def __parameterize__(cls, *vargs): > > .... > > I'm not sure what you're up to here -- maybe it's a reference to > something you did in your own system? But I agree that that kind of > subclassing (perhaps at the metaclass level) ought to be possible.
I'm just trying to flesh out how type parameterization will work under the covers. What I'm proposing is that list[int] would desugar to list.__parameterize__(int). In context: def foo(a: int, b: list[int]) -> int desugars to def foo(a: int, b: list.__parameterize__(int)) -> int The __parameterize__ methods take the parameter(s) as arguments and return an object that can be used to verify that an object is a list with int elements. I've implemented a demo of what I'm driving at, using your metaclass-with-__getitem__ method, taking a PatternedList class as a quick example [1]. My goal with this is to keep user-defined annotation classes on the same level as the built-in types, to prevent them from becoming second-class citizens in this system. Collin Winter [1] - http://tinyurl.com/egabj _______________________________________________ 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
