[Interface-dev] zope.schema -- a plea for fewer dependencies

[Jim Fulton]

On May 26, 2009, at 11:59 PM, Stephen Waterbury wrote:

> [Hope this isn't regarded as OT -- in my mind, zope.interface
> and zope.schema are kind of siblings, and anyway I'm not a
> member of any other zope lists. :) ]

It is OT, but that's OK.

> Ironically, I had just given a zope.schema pitch to someone
> and cited the fact that it depends only on zope.interface as
> a selling point ... only to discover the next day that it had
> grown some new ones -- namely, zope.events and zope.i18nmessages.
> Hrm.  I am sure they were not added without some thought, but in
> looking at how they are used -- esp. zope.events in just
> one place, for object fields -- I just thought I'd ask if
> they are really thought to be necessary.
>
> My opinion is that they aren't, and they play into the feeling
> that using a zope component tends to pull in more stuff than
> one had hoped.  zope.interface is still great, and has no
> dependencies.  I will still use zope.schema even with
> the new dependencies (ok, maybe they are not that new --
> sorry I didn't keep up very well! :), but I would prefer not
> to have them.  For example, it would be nice if the 'notify'
> event for object fields could be some kind of hook that could
> invoke any event system

That's pretty much all it is already. Have you looked at zope.event?   
It's basically a small hook. In fact, here it is:

   subscribers = []

   def notify(event):
       for subscriber in subscribers:
           subscriber(event)


> -- I happen to like Louie, which I
> use in my app -- so I wouldn't have to get this extra
> event system that I don't plan on using.

zope.event would let you easily plug Louie in.

Jim

--
Jim Fulton
Zope Corporation