[Zope3-dev] N-Tuple Adapters

[Phillip J. Eby]

At 12:42 PM 6/3/03 -0400, Shane Hathaway wrote:
>On a more practical note, maybe Zope 3 should use PEAK's implementation of 
>adapters.  However, it seems like it would conflict with Jim's current 
>work on C code for interfaces.

I expect to add some C speedup code soon for the 2 to 5 critical path 
functions in the PyProtocols package.  But the pure Python version is 
already faster than Zope's adapter registries (and several times faster 
than uncached isImplementedBy() calls), at least for the tasks I use them for.

However, PyProtocols is optimized for different things.  I don't really 
*have* adapter registries.  I have protocols that know how to adapt things 
to themselves (similar to Twisted's take on this).  Since there are no 
adapter registries, I have no "placeful" adapter registries.  OTOH, I can 
simulate placefulness with better performance than is possible by searching 
*real* placeful registries, because "contextual protocols" will not need to 
upcall other registries.  (There will be an example of how to do this in 
the docs, once I get them done.)

PyProtocols also may not be optimal for persistent objects that have 
individual declarations (objectImplements), because it would in effect 
require all the adapter factories to be persistent or at least 
picklable.  If one is using only adapters created in persistent modules, of 
course, that would work.  But the adapters provided by the PyProtocols 
package itself aren't picklable.  (I might fix that by the 1.0 release.)

If all of these issues could be resolved, however, Zope *might* be able to 
use the same Protocol class that I use as a base for my version of 
InterfaceClass.  Based on my understanding of Jim's thoughts on what 
interfaces should do and be, I imagine Zope would keep most of its current 
InterfaceClass code even in that case.  My InterfaceClass makes interfaces 
more like ABCs than like Zope interfaces.

I didn't create PyProtocols to compete with or supplant Zope interfaces, 
though.  The main reason for its existence is to provide a universal basis 
for protocol interoperability between frameworks: even ones that have 
different "Interface" base classes.

IMO, it makes about as much sense to demand that all Python programs use 
the same "Interface" type, as it does to insist we all write Python 
programs only using integers.  That is, it'd be both painful and 
unnecessary.  :)  Just as Python has a numeric protocol to allow different 
numeric types to exist, I believe we can have "interface protocols" that 
allow different kinds of interfaces to exist.  PyProtocols is my sketch of 
what I think those protocols are or need to be, combined with reference 
implementations.

When the PyProtocols documentation is finished (there are still several 
pages left to write), I hope to float it (or something like it) as a 
candidate for inclusion in Python 2.4.  I believe it can alleviate Guido's 
concern about a core "interface" type blocking Zope or other frameworks' 
ability to define their own kinds of "interfaces".  PyProtocols 
demonstrates today that two very different interface types can be used 
interoperably, via the same declaration and 'adapt()' APIs.  (I also hope 
to add support for Twisted interfaces soon, but anybody can create and 
register adapters to make their own interface types work with the package, 
as well.  So, the Twisted developers could write and distribute their own 
adapters with their twisted.python.component package, if they wanted to.)