Hi, On Tue, 2009-03-10 at 04:18 +0300, Dan Korostelev wrote:
2009/3/5 Martijn Faassen <faassen@startifact.com>:
Chris Withers wrote:
Martijn Faassen wrote:
I think we can only make the correct determination if we get an idea of the performance implications. If it turns out the C code brings significant speedups in real-world applications, we should create a zope.hookable with a Python + C implementation.
Even if it does bring significant speedups, why does it need to be a seperate package?
It doesn't, but it's already a package that could be easily turned into something with proper documentation (it's mostly there, just hidden), and one of the goals was to reduce C dependencies in zope.component, not add C code to it.
Let's decide that and make a release of zope.component so we could move forward on adapting other packages to recent removal of BBB interfaces.
Here's three variants:
* Move pure python implementation to zope.hookable as a fallback. * Move C implementation to zope.component and drop zope.hookable dependency at all. * Just drop zope.hookable dependency, providing only pure python version of hookable.
I'm -1 on version 3. Whether to keep it as a separate module IMHO depends on the usefulness of the C implementation. If we drop it then we can IMHO live without the standalone package. If we keep two implementations then I'd move both of them to a separate package. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development