Re: [Zope-dev] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Korostelev wrote:
2009/3/5 Tres Seaver <tseaver@palladion.com>:
Log message for revision 97501: Merge the 'tseaver-wo_zope_deferredimport' branch:
Great! Thank you!
- Added a pure-Python 'hookable' implementation, for use when 'zope.hookable' is not present.
Can that pure-python implementation of zope.hookable be merged into zope.hookable as a fallback to a C version if it's not available (like it's done in zope.interface)?
It probably could be (in fact, I prototyped it there first). However, it turns out that zope.hookable has effectively *no* clients beyond zope.component, which meant that I could lose the 'install_requires' dependency altogether by moving the pure-Python bits to zope.component. Thoughts, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrxua+gerLs4ltQ4RAnCJAJ490SAR690RcrSqc9BDGQh/9FrtIQCfXZ1r GNr3pgAVeNxJLjN9MWzYatk= =nVPS -----END PGP SIGNATURE-----
Tres Seaver wrote: [snip]
It probably could be (in fact, I prototyped it there first). However, it turns out that zope.hookable has effectively *no* clients beyond zope.component, which meant that I could lose the 'install_requires' dependency altogether by moving the pure-Python bits to zope.component.
Thoughts,
My thought is that if we treat zope.hookable as a library that stands on its own, which I believe is a principle we should follow, we should do what Dan suggests and move it into zope.hookable. But your discovery that zope.hookable isn't used anywhere else is an interesting one, so we need to weigh that against the opportunity to get rid of a separate library people need to understand. 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. If not, we should get rid of zope.hookable altogether. Regards, Martijn
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? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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. Regards, Martijn
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. 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
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
participants (5)
-
Chris Withers -
Christian Theune -
Dan Korostelev -
Martijn Faassen -
Tres Seaver