On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote: > * Chris McDonough <chr...@plope.com> [2011-09-01 04:27]: > > It wouldn't be the end of the world to have the global registry and the > > global API live in zope.registry, but it doesn't help Pyramid for it to > > be in there, and it probably wouldn't help anyone else either. The > > global API (which includes getSiteManager) is really just a convenience > > feature, and splitting that global API across more than one package > > doesn't seem to make sense to me. > > I guess this is the central issue where we have different opinions. > I don't consider those "just convenience", but rather concept-bearing > of their on right.
"Convenience" and "concept bearing" aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of "fresh start" for zope.component? If so, is anyone willing to promote it, write new docs, etc? > > It might make sense for the entire global API to be in zope.registry, > > but if you take "global API" to mean what it does now that implies > > dependencies on at least: > > > > - zope.event (zope.component.event.dispatch) > > - zope.testing (for addCleanUp of the global registry in > > z.c.globalregistry and other places) > > Yep, those two would be necessary. This is a bit icky for me. I'd rather have something with fewer dependencies, or at least dependencies I actually use. > > It also implies conditional dependencies on zope.security (in > > z.c.hooks.setSite, and other places), which are even now pretty nasty. > > But I don't see where that would come from. As far as I understand it, > hooks.setSite wouldn't be in zope.registry. If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3. Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself. - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
