[Mailman3-dev] PyProtocols vs. Zope Interfaces

[Michael Kato]

Barry,

   I too like the Zope3's new way of specifying "implements".  Does 
zope3's interface still have the packaging issue of being too big and 
zope dependant?  If so, we could talk to the PEAK/pyprotocols people 
and see if they can implement the new zope way, or even implement this 
ourselves.(into pyprotocols and give it back)

   I've-always-wanted-to-muck-with-metaclasses-ly yours,

....maki....


>>    I think I'm beginning to understand the Interface thing.  It seem
>> that in the PEAK PyProtocols the way to say a class implements an
>> interface is:
>>
>> class XXX(object):
>>
>>      def ....
>>
>>      advise(instancesProvide = [IUser])
>
> Doesn't that seem a bit too verbose?  Zope3's New Way would be:
>
> class XXX(object):
>     implements(IUser)
>
> I like that!
>
>>    I was looking for a way to find out if an object implements a
>> protocol, but I think that turns out to be just applying adapt().  One
>> of the points of the Interfaces being eliminating isinstance() like
>> querying.  Just adapt() and use.
>
> Yep.  In Zope3's interfaces now we'd do something like:
>
> user = IUser(obj)
>
> but of course, we'd have to deal somehow with the resulting TypeError.
> (Or use IUser(obj, None) and deal with the None return value).
>
>>    I know you originally mentioned that the Interfaces were mostly for
>> documentation, but do we want to do the adapt() thing?  For instance
>> the contract of get_user() from an IUserStorage says it will return an
>> object that implements IUser.  Once we get that result back do we want
>> to always say user=adapt(result, IUser) before we use the result?  I
>> see one advantage to that being that the backend has some wiggle room
>> in returning non object instances like a module or a class and it'll
>> have a chance for the adapt() voodoo to be worked or people to write
>> real adapters etc.  On the other hand I fear that might be too much
>> engineering.
>
> Me too.  I'd opt for simplicity for now.  If we find we need to start
> adapting objects we can add the machinery to do that.  One place I've
> been thinking about using adaptation is for places where we're going to
> be exposing attributes through things like page templates or variable
> substitutions in mail messages.  In that case, I think we want to 
> figure
> out some way to adapt an object so that /only/ the values we want to
> expose are accessible.