Re: [lxml-dev] Can't get lxml to work with Python 3 (installation with errors, importing works, usage doesn't)
Ok, so I misinterpreted the error trace. The respective code in lxml.etree needs to be somewhat flexible and ended up a bit too fragile. So, if you pass a "non-standard" file-like object, it might end up raising an exception like this.
Here's a fix. Take care to use Cython 0.12.1 when you build from patched lxml 2.2.x sources.
Thanks for the fix! I'm apparently too dumb to apply the .diff using patch (there was always some strange error occuring), so I patched apihelpers.pxi manually. :D When building the patched 2.2.6 sources, which I downloaded from http://pypi.python.org/packages/source/l/lxml/lxml-2.2.6.tar.gz), using Cython 0.12.1 I receive the following error: ---- $ python3 setup.py bdist_egg [...] gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/libxml2 -I/usr/include/python3.1 -c src/lxml/lxml.etree.c -o build/temp.linux-x86_64-3.1/src/lxml/lxml.etree.o -w gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-3.1/src/lxml/lxml.etree.o -lxslt -lexslt -lxml2 -lz -lm -o build/lib.linux-x86_64-3.1/lxml/etree.so building 'lxml.objectify' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/libxml2 -I/usr/include/python3.1 -c src/lxml/lxml.objectify.c -o build/temp.linux-x86_64-3.1/src/lxml/lxml.objectify.o -w src/lxml/lxml.objectify.c:573: error: conflicting types for ‘__Pyx_ImportType’ src/lxml/lxml.etree_api.h:160: note: previous definition of ‘__Pyx_ImportType’ was here error: command 'gcc' failed with exit status 1 ---- I tried the same with the newest SVN sources (lxml 2.3 r74722) and it worked (both, building and the bugfix). For anyone who cares I uploaded the egg: It's available on http://codethief.eu/kram/_/lxml-2.3dev-py3.1-linux-x86_64.egg P.S. Any plans to migrate to a distributed revision control system like Git or preferably (in my opinion) Mercurial? That'd make many things a lot easier. Just take github.com and bitbucket.org which expose a much nicer user interface than SVN does. :) -- Simon Hirscher http://simonhirscher.de
codethief, 25.05.2010 22:57:
P.S. Any plans to migrate to a distributed revision control system like Git or preferably (in my opinion) Mercurial?
No such planning, no. I actually got used to using svk for lxml. Works ok in most cases, lacks a bit of ease compared to Mercurial, but keeps the current repo as is. Stefan
participants (2)
-
codethief
-
Stefan Behnel