Purpose of Zope Interfaces?

I’ve never used Zope interfaces, but you might consider writing a metaclass, which on initialization checks the members of the class against the interface, and raises a runtime exception if a method isn’t implemented.

With Python you don’t have other options. Either have a “compile” step that inspects your code, or dynamically inspect it at runtime.

Zope interfaces can provide a useful way to decouple two pieces of code that shouldn’t depend on each other.

Say we have a component that knows how to print a greeting in module a.py:

>>> class Greeter(object):
...     def greet(self):
...         print 'Hello'

And some code that needs to print a greeting in module b.py:

>>> Greeter().greet()
'Hello'

This arrangement makes it hard to swap out the code that handles the greeting without touching b.py (which might be distributed in a separate package). Instead, we could introduce a third module c.py which defines an IGreeter interface:

>>> from zope.interface import Interface
>>> class IGreeter(Interface):
...     def greet():
...         """ Gives a greeting. """

Now we can use this to decouple a.py and b.py. Instead of instantiating a Greeter class, b.py will now ask for a utility providing the IGreeter interface. And a.py will declare that the Greeter class implements that interface:

(a.py)
>>> from zope.interface import implementer
>>> from zope.component import provideUtility
>>> from c import IGreeter

>>> @implementer(IGreeter)
... class Greeter(object):
...     def greet(self):
...         print 'Hello'
>>> provideUtility(Greeter(), IGreeter)

(b.py)
>>> from zope.component import getUtility
>>> from c import IGreeter

>>> greeter = getUtility(IGreeter)
>>> greeter.greet()
'Hello'

Where I work, we use Interfaces so that we can use ZCA, or the Zope Component Architecture, which is a whole framework for making components that are swappable and pluggable using Interfaces. We use ZCA so that we can cope with all manner of per-client customisations without necessarily having to fork our software or have all of the many per-client bits messing up the main tree. The Zope wiki is often quite incomplete, unfortunately. There’s a good-but-terse explanation of most of ZCA’s features on its ZCA’s pypi page.

I don’t use Interfaces for anything like checking that a class implements all the methods for a given Interface. In theory, that might be useful when you add another method to an interface, to check that you’ve remembered to add the new method to all of the classes that implement the interface. Personally I strongly prefer to create a new Interface over modifying an old one. Modifying old Interfaces is usually a very bad idea once they’re in eggs that have been released to pypi or to the rest of your organisation.

A quick note on terminology: classes implement Interfaces, and objects (instances of classes) provide Interfaces. If you want to check for an Interface, you would either write ISomething.implementedBy(SomeClass) or ISomething.providedBy(some_object).

So, down to examples of where ZCA is useful. Let’s pretend that we’re writing a blog, using the ZCA to make it modular. We’ll have a BlogPost object for each post, which will provide an IBlogPost interface, all defined in our handy-dandy my.blog egg. We’ll also store the blog’s configuration in BlogConfiguration objects which provide IBlogConfiguration. Using this as a starting point, we can implement new features without necessarily having to touch my.blog at all.

The following is a list of examples of things that we can do by using ZCA, without having to alter the base my.blog egg. I or my co-workers have done all of these things (and found them useful) on real for-client projects, though we weren’t implementing blogs at the time. 🙂 Some of the use cases here could be better solved by other means, such as a print CSS file.

1. Adding extra views (BrowserViews, usually registered in ZCML with the browser:page directive) to all objects which provide IBlogPost. I could make a my.blog.printable egg. That egg would register a BrowserView called print for IBlogPost, which renders the blog post through a Zope Page Template designed to produce HTML that prints nicely. That BrowserView would then appear at the URL /path/to/blogpost/@@print.

2. The event subscription mechanism in Zope. Say I want to publish RSS feeds, and I want to generate them in advance rather than on request. I could create a my.blog.rss egg. In that egg, I’d register a subscriber for events that provide IObjectModified (zope.lifecycleevent.interfaces.IObjectModified), on objects that provide IBlogPost. That subscriber would get get called every time an attribute changed on anything providing IBlogPost, and I could use it to update all the RSS feeds that the blog post should appear in.

   In this case, it might be better to have an IBlogPostModified event that is sent at the end of each of the BrowserViews that modify blog posts, since IObjectModified gets sent once on every single attribute change – which might be too often for performance’s sake.

3. Adapters. Adapters are effectively “casts” from one Interface to another. For programming language geeks: Zope adapters implement “open” multiple-dispatch in Python (by “open” I mean “you can add more cases from any egg”), with more-specific interface matches taking priority over less-specific matches (Interface classes can be subclasses of one another, and this does exactly what you’d hope it would do.)

   Adapters from one Interface can be called with a very nice syntax, ISomething(object_to_adapt), or can be looked up via the function zope.component.getAdapter. Adapters from multiple Interfaces have to be looked up via the function zope.component.getMultiAdapter, which is slightly less pretty.

   You can have more than one adapter for a given set of Interfaces, differentiated by a string name that you provide when registering the adapter. The name defaults to "". For example, BrowserViews are actually adapters that adapt from the interface that they’re registered on and an interface that the HTTPRequest class implements. You can also look up all of the adapters that are registered from one sequence of Interfaces to another Interface, using zope.component.getAdapters( (IAdaptFrom,), IAdaptTo ), which returns a sequence of (name, adapter) pairs. This can be used as a very nice way to provide hooks for plugins to attach themselves to.

   Say I wanted to save all my blog’s posts and configuration as one big XML file. I create a my.blog.xmldump egg which defines an IXMLSegment, and registers an adapter from IBlogPost to IXMLSegment and an adapter from IBlogConfiguration to IXMLSegment. I can now call whichever adapter is appropriate for some object I want to serialize by writing IXMLSegment(object_to_serialize).

   I could even add more adapters from various other things to IXMLSegment from eggs other than my.blog.xmldump. ZCML has a feature where it can run a particular directive if and only if some egg is installed. I could use this to have my.blog.rss register an adapter from IRSSFeed to IXMLSegment iff my.blog.xmldump happens to be installed, without making my.blog.rss depend on my.blog.xmldump.

4. Viewlets are like little BrowserViews that you can have ‘subscribe’ to a particular spot inside a page. I can’t remember all the details right now but these are very good for things like plugins that you want to appear in a sidebar.

   I can’t remember offhand whether they’re part of base Zope or Plone. I would recommend against using Plone unless the problem that you are trying to solve actually needs a real CMS, since it’s a big and complicated piece of software and it tends to be kinda slow.

   You don’t necessarily actually need Viewlets anyway, since BrowserViews can call one another, either by using ‘object/@@some_browser_view’ in a TAL expression, or by using queryMultiAdapter( (ISomething, IHttpRequest), name='some_browser_view' ), but they’re pretty nice regardless.

5. Marker Interfaces. A marker Interface is an Interface that provides no methods and no attributes. You can add a marker Interface any object at runtime using ISomething.alsoProvidedBy. This allows you to, for example, alter which adapters will get used on a particular object and which BrowserViews will be defined on it.

I apologise that I haven’t gone into enough detail to be able to implement each of these examples straight away, but they’d take approximately a blog post each.