2009/3/5 Martijn Faassen <faas...@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
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.
The second (or even third, if there's no significant slowdown) variant
seems fine to me personally, because, as Tres noted, there's probably
no consumers for zope.hookable beyond zope.component, so we can safely
merge the packages.
Jim, Philipp, Marius, can you please give us rights on PYPI for
zope.component. My account is "nadako" there, so you can give it to me
and I'll add other people.
WBR, Dan Korostelev
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -