[PEAK] PyProtocols: adapting None

[Marko Mikulicic]

On 30.03.2006., at 18:24, Phillip J. Eby wrote:

> At 06:07 PM 3/30/2006 +0200, Marko Mikulicic wrote:
>> Is there interest in this kind of solution?
>
> No, sorry.  The changed behavior would make it incompatible with  
> PEP 246.
>
> My suggestion would be to consider using RuleDispatch's generic  
> functions instead of adaptation.

My application rotates around the central point of the concept of  
adaptation, like zope does.
It has a framework that allows users to extend using xml  
configuration files which describe adapters, and inserting a new  
behaviour description
system is not possible. Of course I could make my current problem a  
special case and implementing it with some other means but I would like
to use adaptation wherever possible.

I don't see in PEP 246 any rule that states that the result of the  
'adapt' method cannot be None:

<quote>
Finally, if the object cannot determine its compliance, it should
     return None to enable the remaining mechanisms
...
Finally, when
     compliance cannot be determined, this method should return None to
     enable the remaining mechanisms.  If __adapt__ raises any other
     exception, "adapt" just propagates it
...
A failure to adapt the object to the protocol raises an
     AdaptationError (which is a subclass of TypeError), unless the
     alternate parameter is used, in this case the alternate argument
     is returned instead.
</quote>

adapt could already return None if it is passed as the 'default'  
argument, so applications would be already prepared to obtain it as
as an (possibly indirect) result of 'adapt'.


PyProtocols has already a difference between it and PEP 246.
Code that raise TypeError to signal failure to adapt will not behave  
under PyPython like following strictly the PEP 246

the documentation says:

<quote>
These differences are the result of experience using the protocols  
package with PEAK, and advances in the Python state-of-the-art since  
PEP 246 was written (over two years ago). We believe that they make  
the adaptation protocol more robust, more predictable, and easier to  
use for its most common applications.
</quote>

The addition that I'm proposing will not make any code that assumes  
PEP 246 change it's behaviour.
In the worst case, code using this extension will not be portable on  
other implementations of PEP 246.
Since the comparison is by identity on the AdaptedNone object there  
is no possibility that unaware code may miss an adaptation
But this could be stated in the documentation.

The problem is that since the adaptation is optimized using pyrex one  
could not monkeypatch PyProtocols in it's own application.
This addition would be like a hook for customizations.

regards
marko