On Fri, 2011-09-09 at 00:57 -0400, Chris McDonough wrote:
> > I mentioned previously that it's not that much of a stretch to put this
> > code into zope.interface because zope.interface.adapter already defines
> > registry-ish stuff that possesses most of the same concepts as a
> > component registry. It has a class named "AdapterRegistry" already that
> > has a very similar API as a full-on component registry. The full-on
> > component registry really just an API implemented in terms of multiple
> > z.i.adapter.AdapterRegistry instances.
> > With that in mind, and in the interest of moving forward, I'd suggest we
> > just ditch the zope.registry package and move its code into
> > zope.interface. Then there's no renaming to do at all, we can still
> > innovate in the future without necessarily decommissioning a package.
> > As a bonus, we'll have one fewer dependency package.
> > The zope.registry registration machinery sends events when its API is
> > called. It'd be a bit sucky to have z.event as a hard dependency of
> > zope.interface. But it'd be dead easy to change it to only send
> > registration events if zope.event could be imported. I doubt there's
> > anything listening for these events that doesn't also already depend on
> > zope.event.
> > zope.registry also currently provides a minor API in the way of an
> > "adapts" decorator. This could (and should) be moved back into
> > zope.component; it's actually not used internally by zope.registry now
> > (although some decoy imports would make you think so if you look at
> > zope.registry.__init__).
> First cuts of this at:
I have merged these two branches to their respective trunks:
If no one has issues with this, I will make releases of both within the
next few days.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -