lxml - The Python XML Toolkit November 2004

lxml@python.org

5 participants
5 discussions

[lxml-dev] some comments about the file shuffling
by Martijn Faassen 26 Nov '04

26 Nov '04

Hi there, Just took a glance at the reshuffling branch. I'm glad you're doing this work. Some comments about it though: it's now lxml.etree.etree and lxml.etree.dom in the old situation, and intended, it was just lxml.etree and lxml.dom i.e. there's no need for this separate etree package, we can just put the modules in the lxml container package. dom has nothing to do with etree; it's a completely different way to layer over libxml2. Where did the testrunner test.py go? I see you moved all tests into a separate top-level test directory, but I've been following the pattern in use in Zope (2 and 3), Schooltool, Pypy and Twisted, to name just a few Python projects, where there's a 'tests' or 'test' directory in or next to the package/module being tested. Since these different subpackages can be developed more or less in isolation, this seems to be like a good thing to do, instead of putting them all in the same place. They're unit tests, and belong with the unit they're testing. I see you what looks like an empty __init__.py in the etree package. While that works fine on unixy systems, Windows tools like winzip sometimes have issues, not extracting empty files. I don't use Windows but want my software to be portable to it if possible, so I've therefore made it a habit to place a marker comment "# this is a package" in any __init__.py that I create. Regards, Martijn

2 2

[lxml-dev] Re: etree compile problem
by Martijn Faassen 25 Nov '04

25 Nov '04

Victor Ng wrote: > Does etree in the trunk line compile for you? Yup, it seems to work just fine: > make python2.3 setup.py build_ext -i running build_ext building 'lxml.etree' extension creating build creating build/temp.linux-i686-2.3 creating build/temp.linux-i686-2.3/src creating build/temp.linux-i686-2.3/src/lxml gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/libxml2 -I/usr/include/python2.3 -c src/lxml/etree.c -o build/temp.linux-i686-2.3/src/lxml/etree.o -w gcc -pthread -shared build/temp.linux-i686-2.3/src/lxml/etree.o -lxml2 -o src/lxml/etree.so building 'lxml.dom' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/libxml2 -I/usr/include/python2.3 -c src/lxml/dom.c -o build/temp.linux-i686-2.3/src/lxml/dom.o -w gcc -pthread -shared build/temp.linux-i686-2.3/src/lxml/dom.o -lxml2 -o src/lxml/dom.so What kind of messages are you getting? Regards, Martijn

2 4

[lxml-dev] etree doesn't build for me
by Victor Ng 23 Nov '04

23 Nov '04

Hi all, I've been reorganizing the lxml/etree and vlibxml2 stuff and I'm basically done wedging vlibxml2 into the lxml.vlibxml2 package - but I can't get etree to build, much less run any unittests. Does this work for anyone else? The trunk line doesn't seem to build for me. vic --- "Consequences, Schmonsequences, as long as I'm rich." -- Looney Tunes, Ali Baba Bunny (1957, Chuck Jones)

1 0

[lxml-dev] vlibxml2 and lxml
by Martijn Faassen 19 Nov '04

19 Nov '04

Hi there, Back from my honeymoon I see that Victor has released vlibxml2. Cool! Thanks Victor! I hope that we can still converge it all into a single package -- vlibxml2 aims to do a fairly low-level straightforward mapping for parts of the libxml2 API, as I understand it, while lxml aims to raises the level of the API. The approaches don't need to exclude each other however and pooling them together could help both. Victor, I'm curious about the reasons why you didn't use the existing lxml infrastructure (svn, mailinglist, etc) to do what you've been doing? Were you under the impression that what you were aiming at is outside the scope of lxml? I think people would prefer there not be two pyrex based wrappers for libxml2. Is there anything we can change with lxml so that you'd be happy to merge the projects? I see that Victor changed his license from GPL to BSD (though the README.txt of the 0.1.177 release still says it's GPL-ed). That's great; it means no matter what happens with lxml/vlibxml2 convergence, lxml can hopefully at least 'borrow' the memory management code from vlibxml2. Thanks again Victor! Regards, Martijn

4 17

[lxml-dev] victree
by Martijn Faassen 12 Nov '04

12 Nov '04

Hi there, I now found the 'victree' module (as opposed to the empty package) in vlibxml2. Quite interesting. The Python wrapper approach certainly makes it a lot less large than the Pyrex strategy, though I have the hope this will be made easier with vlibxml2 as a base too. etree.pyx would have the benefit of being faster, too, as many of the operations are happening at C speed. What are your plans for victree? Regards, Martijn

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

lxml - The Python XML Toolkit November 2004