[Zope3-dev] Re: Notice: zope.interface is now a separate project

Jeff Shell eucci.group at gmail.com
Sat Mar 4 16:36:11 EST 2006


On 3/3/06, Thomas Lotze <thomas.lotze at gmx.net> wrote:
> Am Mon, 27 Feb 2006 15:56:16 -0600 schrieb Paul Winkler:
>
> > We are planning to do this to a number of other packages:
> >
> > zope.i18n
> > zope.i18nmessageid
> > zope.deprecation
> > zope.exceptions
> > zope.tal
> > zope.component
>
> What was the reason for choosing these and not choosing others? What
> about, e.g., zope.schema? I think that one's as interesting for non-Zope
> use as, e.g., zope.interface and zope.component.

I agree. I think zope.schema is integral. It has so many potential
uses, not to mention that it really makes 'zope.interface' a complete
design by contract system since it can be used to enforce constraints
on data / arguments / etc. It's also fiendishly good for formatting
and translating data to/from objects. I've used zope.schema to
serialize values to and from reStructuredText style fields, as a way
to do fancy declarative programming in Python through deferred object
constructors that used zope.schema to enforce/convert arguments. This
latter one was in an experiment in using the zope component
architecture in a totally not-Zope application.

I highly recommend adding zope.schema to this list. I believe its
dependencies are pretty small, and I think it's a good system to use
for people who like the concept of 'static type safety' while being
much more adaptive, useful, usable, and flexible than most basic type
systems.

I think that zope.schema, zope.component, and zope.interface could be
highly effective when combined with a tool like 'sqlalchemy'.

--
Jeff Shell


More information about the Zope3-dev mailing list