On 3/3/06, Thomas Lotze <[EMAIL PROTECTED]> 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

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

Jeff Shell
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to