I am in the process of converting some of my code to use zope.schema instead of a similar thing that I independently invented. Since I am also planning on using Foolscap, and since Foolscap has a schema module, I compared zope.schema and foolscap.schema, and to me they seem to have much overlap in design intent. In particular, in the zope.schema use cases ...
... one of the cases cited is:
Method uses schema for its arguments
A more general case than above, any method can provide a schema to which its arguments should conform. This schema can be used to create a form or to validate arguments upon any call.
... which seems almost exactly the foolscap.schema use case. Moreover, zope.schema has "constraints" that are similar in concept to the ones in foolscap.schema.
So I was wondering -- would it make sense to use zope.schema in Foolscap? I plan to use them in my code, so from my own selfish point of view that would be nice because it would unify everything relating to the schema concept, and I wouldn't have to have separate usages and imports of zope.schema and foolscap.schema.
Although "There should be one -- and preferably only one -- obvious way to do it" doesn't necessarily -- or even that often -- apply to libraries, this might be a good case for applying it, for reasons somewhat similar those underlying twisted's adoption of zope.interface.
A nice practical factor is that zope.schema has been packaged as a separate namespace module, similarly to zope.interface.
I'd be interested to know your thoughts.