lxml - The Python XML Toolkit July 2005

lxml@python.org

11 participants
12 discussions

[lxml-dev] Python interpreter segfault setting element tail
by Kieran Holland 03 Nov '05

03 Nov '05

Thanks for lxml - very nice. Unfortunately the following fragment causes my python interpreter to crash and burn: ---------------- from lxml import etree root = etree.fromstring('<html><p></p>x</html>') for elem in root: elem.tail = '' ----------------- System: gentoo linux 2004.3 on x86 python 2.4.1 lxml 0.7 (and 0.6) libxml 2.6.19 Kieran

2 2

[lxml-dev] lxml on windows action
by Martijn Faassen 04 Aug '05

04 Aug '05

Hi there, Before the lxml 0.8 release, I'd like to get the windows build and release process in place. So far I've heard about 3 or 4 people who got it built on Windows, but I'd like an official version that can be hosted on the lxml website that we can update for each release. I'm not able to maintain this myself, so this is a request for a regular maintainer. Here is what I think are the requirements: * should be easy to build. That means the setup.py in lxml should be adjusted so that typing in the right command will build the right thing on windows. * should include libxml2 + libxslt so that users do not have to go out and install the right versions of that. These versions should ideally not conflict with other versions of those libraries that may already be installed. Does not need to contain the included libxml2/libxslt bindings though; lxml is supposed to replace these. * should be easy to install on Windows. * it should be easy to run the tests on Windows (I heard there were some problems with getting it going). * whenever I pull a release, I need a specific person who I can contact so that I can make sure the windows package for this release will be created as well. This way, I can put that online as well on the lxml website at release time or shortly after release, next to the source release. Opinions? Volunteers to work on aspects of this? Regards, Martijn

4 4

[lxml-dev] lxml - DOM
by cazic 27 Jul '05

27 Jul '05

Hi, I would like to implement a DOM wrapper for Libxml2. We heavily use a Delphi wrapper for Libxml2 at work and for me it would be nice to have a similar thingy on the Python side - for easy scripting. I talked with Martijn some time ago about such an attempt and he directed me to the aready existing initial source for a lxml DOM wrapper. After having consulted the implementation of pxdom, I started an initial implementation. Since consider myself still a Python newbie and was new to Pyrex, I came up with a code more focused on experimenting with those languages than trying to fit into the already existing lxml infrasctructure. The main difference between the lxml approach and this experiment is that it uses an additional layer of classes to map to Libxml's nodes. With such a layer, which already cares about the peculiarities of the Libxml2 library, setting up a DOM layer on top felt quite easy. This is all not new and similar to lxml's etree _NodeBase or _DocumentBase classes, but with the difference, that instances of such classes or specialized derived classes would sit on the "_private" field of a Libxml2 node, rather than a _ProxyRef structure. This has the following pros: 1. Such accessor classes can hold additional information like the parent node of Libxml2's namespace nodes (Libxml2 does not have a field for this), so this information need not be obtained for every interface, but is stored only once and managed at a distinct position. Another scenario could be a work-flow where you modify the node-tree via the DOM API, but want to serialize it in an ElementTree fashion; so the fact that namespace declarations need probably to be rearranged, since we used DOM previously could be saved in the document accessor object. 2. One can design an user interface which is disattached from any internal lxml classes and therefore their methods. (I dunno if Python or Pyrex has the concept of "protected" methods, so only visible to the code of the classes itself. If so, then this argument does hold.) So internal methods wouldn't interfere with user interface methods. 3. One can use pure Python as well (at least I hope so, didn't try it myself :-)) to create new user APIs. So if you need a custom XML API, then you can use the accessor classes via Python and pick the functionallity use need. This holds true if you are not intending to use some fancy XML operations not supported by the accessor classes. So here the accessors act more like Libxml2 Python bindings than a specific API. The cons: 1. An additional layer of objects will be slower: etree: 1 _ProxyRef structure per interface 1 _DocumenBase, _NodeBase, ect per interface object accessors: 1 accessor object per node 1 _ProxyRef structure per interface object 1 interface object This is all an experiment for me and I don't have any intention to modify lxml's current philosophy; so if any one is interested in a DOM API in the house of lxml: I appretiate comments about the sanity of such an approach and would change my direction if it does not fit into lxml. Note that the DOM API is written in Python in that module. I should change this due to better performance and write it in Pyrex, but currently I dunno how to use class constants (is there a way?) with extension types - needed for the node-types in the "Node" class. I'll attach the current code (Martijn, it is almost the same I send you 2-3 weeks ago), together with a modified tree.pyd and the test script I used for playing with it. Ah, and it needs Libxml2 2.6.20, due to a new Libxml2 function. Greetings, Kasimier

2 1

[lxml-dev] fromstring('') segfaults
by dharana 26 Jul '05

26 Jul '05

>>> import lxml.etree >>> lxml.etree.fromstring('') Segmentation fault -- dharana

3 4

[lxml-dev] iterparse support ?
by Olivier Grisel 23 Jul '05

23 Jul '05

Hi list, Is there any plan to add the 'iterparse' method (or some kind emulation) of emulation to lxml.etree? I don't really know libxml2 but it should be possible to reproduce the iterparse semantics by using libxml2's SAX API, shouldn't it? Apparently, the yum developpers (the fedora package manager) found this missing feature to be a decisive drawback that prevented them to switch from ElementTree to lxml.etree: https://www.redhat.com/archives/fedora-devel-list/2005-May/msg00328.html I also wanted to implement a lxml.etree based XML parser plugin for rdflib, but I guess it's not wise to load all the XML tree in memory before actually constructing the RDF graph. BTW, the missing iterparse method should be mentionned on http://codespeak.net/lxml/compatibility.html Best, -- Olivier

2 1

[lxml-dev] Python interpreter segfault assigning to elem.tail
by Kieran Holland 22 Jul '05

22 Jul '05

Thanks for lxml : great library. Unfortunately the following fragment causes my python interpreter to crash and burn: ---------------- from lxml import etree root = etree.fromstring('<html><p></p>x</html>') for elem in root: elem.tail = '' ----------------- System: gentoo linux 2004.3 on x86 python 2.4.1 lxml 0.7 (and 0.6) libxml 2.6.19 Kieran

1 0

[lxml-dev] bazaar-ng compat patch applied
by Martijn Faassen 09 Jul '05

09 Jul '05

Hi there, I'd like to thank Olivier again for his patch, which I just applied and is now in svn. I've also integrated the unit tests that he contributed. I did modify the patch a bit to deal with a potential memory leak, but overall it was very thorough, including tests. This should make it more likely you can port over your ElementTree code to lxml without problems. Thanks! Regards, Martijn

1 1

[lxml-dev] lxml on Windows - hints?
by Anton Stonor 07 Jul '05

07 Jul '05

Hi there, Being uplifted by Martijns presentation of lxml at EuroPython I really would love to move away from DOM XML-handling and use this beauty instead. However, I can't figure out to build it on Windows. I've been playing with MinGW but feel like walking in the dark. Any hints (such as: _can_ you use MinGW at all for this), succes stories or even better: prebuilded pyd/dlls ? /Anton

3 3

[lxml-dev] advantages of libxml
by Slou 05 Jul '05

05 Jul '05

Hi! Here are several features I miss in lxml: - ability to get namespace of the node without parsing .tag property (which is concatenated on library side, so double amount of meaningless work is done) - ability to get short name of the node - ability to get parent node without .xpath('../')[0] which seems overkill to me - ability to get absolute xpath of node I may be wrong and some things that I want may be inconsistent with lxml design and usage patterns, correct me in this case. Anyway lxml is the best xml-processing library for Python, thanks for your work!

4 6

[lxml-dev] Type returned by xpath
by Florian Wagner 01 Jul '05

01 Jul '05

Hi, I want to be able to do something like this with lxml for attr in doc.xpath('//somenode@someattr'): attr.text = 'sometext' But since the xpath method returns strings for the attributes this is not possible. Is there some way to make xpath return a list of node objects instead? Greetings Florian

2 1

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 July 2005