[Python-Dev] Sneaky 'super' instances
Phillip J. Eby
pje@telecommunity.com
Thu, 12 Jun 2003 08:55:17 -0400
At 11:29 AM 6/12/03 +0100, Moore, Paul wrote:
>From: Moore, Paul
> > Specifically, requirement (e) in the PEP considers precisely
> > the case where neither the "protocol" nor the "object" need
> > to know about the adapt() mechanism. Sadly, the reference
> > implementation provided does not support requirement (e).
>
>And doubly sadly, I see that PyProtocols doesn't either. I'd
>suggest that you add this, and then maybe your "chicken and egg"
>issues will go away. Or maybe I've missed something :-)
Open protocols solve the chicken and egg problem by allowing one to make
declarations about third-party objects. The problem with __adapt__ and
__conform__ is as you say: people have to write things to support
them. PyProtocols bootstraps this by providing plenty of objects, base
classes, adapters, and wrappers that support __adapt__ and __conform__.
While it's true that you can't use 'adapt(ob,file)' meaningfully, there's
nothing stopping you from saying 'declareImplementation(file,[IFile])' and
'adapt(ob,IFile)'. (And the user can say
'adviseObject(ob,provides=[IFile]) before passing you 'ob'.) The point of
the open protocol mechanism is that you can make these declarations
relative to a specific package's interfaces, *without* requiring there to
be a common standard. (Because you can define the relationships between
different packages' interfaces.)
To put it another way... it isn't necessary that 'file' be a protocol in
the Python core. If I write code that needs a file, I define a protocol
that means whatever I want it to mean, and if files satisfy that
requirement, I declare that file satisfies it. If a user has an object
that they believe satisfies my requirement, they declare that it does
(whether they created it or somebody else did). As long as I use an "open"
protocol (one that will accept declarations), then this works.
At present, there are only three implementations of open protocols (that
conform to PyProtocols' API): protocols derived from PyProtocols base type,
Zope interfaces, and Twisted interfaces. However, in principle, one could
use any other interface type that had the ability to be told what objects
support or adapt to the interface. To use them with PyProtocols, one would
need an adapter that translated their current API to the PyProtocols API,
like the two I wrote for Zope and Twisted.
Anyway, PyProtocols provides enough functionality around PEP 246 to allow a
great deal of useful development to happen without ever writing an
__adapt__ or __conform__ method. So, from my point of view it breaks the
chicken-and-egg problem because if you write an app using PyProtocols to
define interfaces and adapt to them, then end users can extend it. They
don't have to write __conform__ methods, and you don't have to write
__adapt__ methods. You both use the declaration API, unless you need to do
something that's very unusual indeed.
The declaration API (all the functions named 'declareSomething' or
'adviseSomething') is the main addition to PEP 246 (aside from some minor
refinements to the specification of adapt()). That is where I'm most
interested in third-party critique, especially from developers of other
interface systems than the ones I've already written adapters for, and for
that matter from the Zope and Twisted developers for their perspective on
whether PyProtocols' architecture would be reusable for them to support
additional capabilities in their interface types (since PyProtocols
declaration API is a superset of the declaration facilities provided for
Zope and Twisted interfaces currently).