![](https://secure.gravatar.com/avatar/e9e506a1c7f5e3394bcf93e27b48b529.jpg?s=120&d=mm&r=g)
[Jeremy Hylton Tue, Sep 23, 2003 at 09:50:59PM -0400]
On Tue, 2003-09-16 at 11:46, Christian Tismer wrote:
[many more binaries than expected]
btw, i forgot all about it: this is mainly the Zope-Database (ZODB) which is independent from Zope and has quite some parts written in C, for performance reasons ASFAIK. I'd say they are applying a common technique with high-level-languages: rapidly prototype in Python and reimplement the speed-relevant parts in C (and maintain it). It's rather obvious how PyPy could help here :-)
Absolutely. Zope can reverse its path and move its core back to where it belongs: Python.
In fact, Zope3 started with all Python implements of ZODB. A few parts of it have been rewritten in C over time. Performance is the main goal, but another noteworthy reason to use C is to reduce memory usage. Pure Python objects consume a lot of memory. C extension types can be fairly small. (datetime is a good example.)
Does pypy have a plan for memory or is performance the primary goal?
allowing to have a small memory footprint is certainly a goal. PyPy aims to make it a lot easier to make decisions regarding space<->time tradeoffs. So Zope3 could e.g. use their own completely compliant python interpreter optimized for memory consumption. Do the parts of Zope3 that got rewritten in C still have a complete python counterpart? Do the unit-tests run on both of them? cheers, holger