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 systems. 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 Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
