At 09:56 AM 5/9/2006 -0700, Mike Krell wrote: >On 5/9/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >>At 06:19 AM, 9 May 2006 +0000, Talin <[EMAIL PROTECTED]> wrote: >> >Now, generic functions are good at dealing with these kinds of >> >situations. However, generic functions (as they are usually concieved) >> >can only deal with specific, concrete types, not "types which satisfy >> >some constraint". >> >> [Discussion of Haskell's typeclasses snipped] > >I tried to follow the recent generic functions / adaptation in Python >3000 discussion, but the details quickly went over my head. Could >Phillip or some other kind soul give a simple example / summary of how >the final proposal addresses this "types which satisfy some >constraint" question?
The idea is that constraints are based on what operations can be performed on the type. In today's duck typing, you do this by seeing if the object has an attribute -- the method for performing the operation. So you're querying the object for the operation In a generic function/typeclass world, you would instead ask the operation if it supports the object... almost as if you could say 'len.supports(someobject)' instead of 'hasattr(someobject,"__len__")'. Typeclasses then extend this idea to say that you could declare a particular parameter of a function as having to be supported by len(), operator.getitem() and so forth... or for convenience's sake, you could define a typeclass like "read-only sequence" to mean an object can be used with len(), getitem() and iter(). You would then use that typeclass to define parameter types. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
