adapters.py - a sure sign that you're not using Zope 3 enough

edit: heh... Freudean slip - I originally titled this 'annotations.py - ....'

There is a kind of worrying (well, perhaps not so worrying, but it does annoy me) precedent being set in a few places:

adapters.py

In Zope 3, adapters are everywhere. Views are adapters (multi-adapters, in fact). Namespace traveral is done with adapters. Regular traversal is done with adapters. And well-designed Zope 3 code tends to use adapters a lot:

• One interface for each logical component or piece of functionality
• One or more adapters (or utilities) providing the functionality of a particular interface

Of course, some "base" objects, like content objects, are not looked up as adapters and provide some interface directly, but they tend to be the context of adapter lookups for other interfaces.

Usually, though, when something is context-dependent, it tends to be an adapter. You adapt a content object to IAnnotations via an annotations-adapter to be able to annotate it. You adapt an object to ISized to work out its size. You adapt an object to ISlapTheMonkey to slap the monkey attached to this particular context.

... so why would you put all of them in a single file?

That some functionality is provided by an adapter should be a consequence of the design. Logically related functionality should live in the same module (file), and each module should have a clear boundary of responsibility.

I guess my point is - adapters are not special. They are just a way to modularise your code and separate concerns. If they excite you so much that you want to keep them on their own little pedestal in adapters.py, that's great (you've been drinking the kool-aid), but if you keep using them, they'll just become a natural part of your toolset and you'll use them all over the place, where they make sense.