On Tue, Mar 30, 2010 at 5:44 PM, Martin Aspeli <optilude+li...@gmail.com> wrote: > Hanno Schlichting wrote: >> It simplifies the release process for Zope2. In most cases upgrading >> to a new version of Zope2 won't involve any changes to C code. If the >> C code is split out, we won't have to release any new Windows binary >> eggs of any kind. Upgrades on systems without a compiler are also >> going to be easier. > > +1 > > I'm generally for it, we just need to (a) make sure we're not going to > negatively impact performance if we can help it and (b) explain our > rationale.
This is all going to be transparent to everyone. We've already split out Acquisition, ExtensionClass (ComputedAttribute, MethodObject) in the same way. Note that the packages I'm proposing to split out have no Python fallback. The C code which we might want to turn into optional optimizations at a later point, would follow the same standard we already use in the Zope Toolkit. So there won't be any new kind of risk. For example zope.i18nmessageid and zope.interface use this approach. Hanno _______________________________________________ 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 )
