[PEAK] Type and class adaptation

Phillip J. Eby pje at telecommunity.com
Fri Nov 19 13:53:53 EST 2004


At 06:21 PM 11/19/04 +0100, Radek Kanovsky wrote:

>This method failed on ambiguity when dispatching arg=int.

Right, because the system doesn't know that 'issubclass(x,A)' implies 
'issubclass(x,B)' if A is a subclass of B.


>So there
>should be some ITest that helps. Looking at dispatch.ClassTest I have
>made slight modification of it that resulted to 'IsSubclass' test:
>
>     [typeDescriptor.when("arg in IsSubclass(int)")]
>     def typeDescriptorForInt(arg) ...
>
>     [typeDescriptor.when("arg in IsSubclass(myint)")]
>     def typeDescriptorForMyInt(arg) ...
>
>This works fine. I think that 'issubclass(t1, t2)' expression can be
>safely replaced by IsSubclass test directly by predicate parser.

Yep.  I'm planning at some point to actually make certain parts of the 
generic function parser support replacing test expressions in this fashion 
-- using a generic function to determine what's replaceable, so that it 
will be extensible for other plain Python -> ITest conversions.


>Has anybody some solution or opinion? Did I miss something?

Not that I can see.  It's a good solution, and a very nice use of the 
framework.  I'll doubtless be adding something very similar at some 
point.  It's also somewhat similar to how class and attribute metadata will 
likely be registered in future versions of PEAK.

Also, you didn't mention if you were doing this, but you can also use your 
generic function as an adapter, if you want to be able to use adapt() or 
ITypeDescriptor().  Just use something like:

     protocols.declareAdapter(
         typeDescriptor, provides=[ITypeDescriptor],
         forTypes=[type,ClassType]
     )

And then you can use ITypeDescriptor(int), or adapt(int,ITypeDescriptor).




More information about the PEAK mailing list