[Zope-dev] Constant values defined in interfaces

[Chris McDonough]

Tres Seaver wrote:
> Chris McDonough wrote:
>> Using an interface class for a constant "container" would often be handy but it
>> might be an inappropriate use of interface classes.  FTR, I do often put
>> constants in an "interfaces.py" module at module scope (if there are more than
>> one related, sometimes in a dictionary or within a non-interface class
>> statement) in order to not feel I need to create some "constants.py" module.
>> Maybe we could just agree that doing so isn't some sort of violation of intent?
> 
> If constants are part of the spec for an interface, then placing them at
> module scope as peers of the interface seems fine to me.  In that case,
> the docstrings of one or methods would presumably refer to them, e.g.
> describing allowed valeus for an argument.

These are usually not part of any spec for any interface.  They are just plain
constants, e.g.:

BROWSER_NAMESPACE = 'http://namespaces.zope.org/browser'

I put items like this at module scope in interfaces.py.

Sometimes (if I get really wild), I'll put a dict like the below in "interfaces.py":

NAMESPACES = {
   'BROWSER':'http://namespaces.zope.org/browser',
   'ZOPE':'http://namespaces.zope.org/zope'
   }

And sometimes I'll do the thing you think is too-clever in interfaces.py:

class NAMESPACES:
    BROWSER = 'http://namespaces.zope.org/browser'
    ZOPE = 'http://namespaces.zope.org/zope'

But that's neither here nor there; in every case, the data structure gets
defined at module scope in interfaces.py, even though the data structure has
nothing to do with the other interfaces in the file.  Putting these things in
interfaces.py is just taking advantage of the fact that it's fine that other
modules depend on it, because it typically depends on nothing except
zope.interface itself.  I think this pattern is fine; the alternative is
creating another module that contains constants which should also not depend on
anything else.

- C