1.1.9.5 protocols.twisted_support -- Support for Twisted Interfaces

1.1.9.5 `protocols.twisted_support` -- Support for Twisted Interfaces

Importing this module enables experimental support for using Twisted 1.1.0 Interface objects with the protocols package, by registering an adapter from Twisted's MetaInterface to IOpenProtocol. The adapter supports the following subset of the declaration API:

Only protocol-to-protocol adapters defined via the protocols declaration API will be available to implication listeners. If protocol-to-protocol adapters are registered via Twisted's registerAdapter(), implication listeners are not notified.
You cannot usefully create a ``subset'' of a Twisted interface, or an adaptation from a Twisted interface to another interface type, as Twisted insists that interfaces must subclass its interface base class. Also, Twisted does not support transitive adaptation, nor can it notify the destination interface(s) of any new incoming adapter paths.
If you register an adapter factory that can return None with a Twisted interface, note that Twisted does not check for a None return value from getAdapter(). This means that code in Twisted might receive None when it expected either an implementation or an error.
Only Twisted's global adapter registry is supported for declarations and adapt().
Twisted doesn't support classes providing interfaces (as opposed to their instances providing them). You may therefore obtain unexpected results if you declare that a class provides a Twisted interface or an interface that extends a Twisted interface.
Changing the __bases__ of a class that has Twisted interfaces declared for it may have unexpected results, because Twisted uses inheritance of a single descriptor to control declarations. In general, it will only work if the class whose bases are changed, has no declarations of its own.
Any adapter factory may be used for protocol-to-protocol adapter declarations. But, for any other kind of declaration, NO_ADAPTER_NEEDED and DOES_NOT_SUPPORT are the only adapter factories that can be used with Twisted.
Twisted interfaces do not conform to protocols package ``shortest path wins'' semantics. For protocol-to-protocol adapter declarations, only one adapter declaration between a given pair of interfaces is allowed. Any subsequent declarations with the same source and destination will result in a ValueError. For all other kinds of adapter declarations, new declarations override older ones.
You cannot extend both a Zope interface and a Twisted interface in the same protocols.Interface. Although this may not give you any errors, Twisted and Zope both expect to use an __implements__ attribute to store information about what interface a class or object provides. But each has a different interpretation of the contents, and does not expect to find ``foreign'' interfaces contained within. So, until this issue between Zope and Twisted is resolved, it is not very useful to create interfaces that extend both Zope and Twisted interfaces.