[PEAK] The road to PyProtocols 1.0

[Phillip J. Eby]

At 01:26 AM 5/30/04 -0500, Ian Bicking wrote:
>On May 30, 2004, at 12:43 AM, Phillip J. Eby wrote:
>>* Raise 'AdaptationFailure' instead of 'NotImplementedError'.
>>'AdaptationFailure' should subclass 'NotImplementedError' and 'TypeError'.
>>
>>* Check if anybody's using the 'factory' argument to 'adapt()', and if 
>>not, get rid of it.
>>
>>* If 'factory' isn't used anywhere, consider ditching the second 
>>parameter passed to adapters.  That is, instead of calling 
>>'someadapter(ob,proto)', just call 'someadapter(ob)'.  This would give 
>>PyProtocols adapters the same calling signature as e.g. Zope adapters.
>
>I am in FormEncode, but maybe I shouldn't be.  Basically I allow objects 
>to either provide an attribute, or an adapter, and lazily I've only ended 
>up using attributes -- i.e., the factory gets ob.validator instead of 
>actually registering an adapter for ob -> IValidator.
>Frankly I still don't know what I'm doing with interfaces and adapters, or 
>how they should really fit into the system, so I've fumbled around with 
>different ways of using it.

Okay, I've *finally* had a look at the FormEncode source (after a few 
weeks' delay caused by me working day and night finishing out a new room 
for my wife's store).  Anyway, AFAICT, you could drop the 'factory' 
argument by simply putting this code right after the definition of 
_validatorToHTMLView:

     protocols.declareAdapter(_validatorToHTMLView, provides=[IField], 
forTypes=[object])

Then, the _validatorToHTMLView function will be used to adapt any object by 
default.  (Note that PyProtocols includes 'object' in the MRO even of 
classic class objects.  That is, it treats the MRO of a classic class 
instance as '(__bases__ in classic MRO order, InstanceType, object)', so 
you can actually define an adapter for "any classic class instance" by 
declaring an adapter for 'InstanceType'.  But 'object' suffices to cover 
all bases.)

Given the lack of any other votes for keeping the 'factory' argument 
around, I intend to drop it and thus move 'adapt()' a little closer to 
being a "pure" PEP 246 implementation, while edging closer to getting rid 
of the second argument to adapters.