[Python-3000] PEP 3100 Comments

[Phillip J. Eby]

At 09:56 AM 5/9/2006 -0700, Mike Krell wrote:
>On 5/9/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 06:19 AM, 9 May 2006 +0000, Talin <talin at acm.org> 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.