* Chris McDonough <chr...@plope.com> [2011-09-06 20:06]: > 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?
Yes, I like the idea of a "fresh start" (or at least "proper clean up") quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages. > > > 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. Isn't that a little too black and white? I find value in the idea of removing the dependencies to ZODB, ZCML and zope.security, while leaving zope.event/zope.testing in place. > 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. I agree, porting "the whole hairball" is way too much, and I definitely wouldn't want to burden you/Pyramid with that. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting _______________________________________________ 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 )
