On Wed, Mar 18, 2015 at 5:20 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Maciej Fijalkowski schrieb am 11.03.2015 um 15:28:
What it would take to include lxml-cffi (https://github.com/amauryfa/lxml/tree/cffi) as an official part of lxml?
The actual functional differences aren't all that big AFAICT, but the problem is that the syntactic changes in the cffi based modules are scattered all over the place. That prevents a direct integration of the two in one code base without an almost complete duplication of the code.
OTOH, as long as someone has to maintain the cffi based code separately anyway, I don't see the advantage of having it in the same repo as lxml itself.
The main benefit is really the release cycle + "officializing" the lxml-cffi in a way that people who install lxml can directly use it with pypy without having to look for yet another module. If I put all the cffi changes in one spot can this be done?
It works better on PyPy (with the original lxml being slow and prone to bugs, notably segfaulting for me)
Yes, cpyext is still buggy and incomplete in some corners and far from optimised. I'm sure PyPy can be improved here, though.
Stefan
I know you believe it's just a matter of engineering, but we have to agree to disagree a bit. Yes, cpyext CAN be made to be a little better and perform a little better, but there is just no way it can ever get anywhere close to what we can get with cffi.