Mailman 3 March 2006 - lxml - The Python XML Toolkit

[lxml-dev] Speed-up for moving elements inside the same document
by Stefan Behnel 06 Mar '06

06 Mar '06

Hi, I decided to dislike the idea of deep-traversing a tree (changeDocumentBelow) whenever its root element is moved to a different parent. So I tried to come up with some cases where this is not necessary. One such case is this: ----------------------- from lxml.etree import Element, SubElement a = Element('{a}test') # create ten children with a child each which has another child map(SubElement, map(SubElement, map(SubElement, [a]*10, ['{ns%s}e'%i for i in range(10)]), ['{x}c1']*10), ['{y}c2']*10) for i in range(100000): el = a[0] a[-1] = el ----------------------- Here, we basically change the order of the elements below a single parent. This case gets about 20% faster on my machine if we skip the traversal in changeDocumentBelow. It is obviously not necessary, since the document reference is not changed anyway. If the tree structure below the moved element is bigger, the gain also increases. I added a third argument to the function that switches recursion on or off. It is set to False by the calling functions if the moved node and its new parent are in the same document. If this is the case, it means that all their children must also be in the same document (by induction). I tried some other cases, but most of them seem to induce infinite loops in the libxml2 calls - I'm not quite sure why. Anyway, this one is a simpler one and works as expected. I would like to apply the attached patch, so, if others are interested, I'd be glad to get some feedback if it changes something in their real-world use cases... Stefan

1 0

[lxml-dev] Request for help on testing new libxml2 feature
by Andreas Pakulat 06 Mar '06

06 Mar '06

Hi, regarding the remove-redundant-namespaces issue there are news: kbuchcik implemented the xmlDOMWrapReconcileNamespaces in tree.c of libxml2 so it should remove redundant NS decl. However neither do I have any experience with libxml2 nor do I have the time to dig into it so that I can build a test program for this. Thus I ask you guys here, who surely are libxml2 experts, if you could help me out here. Either some "hack" for lxml that allows me to test this or a small programm that takes an xml file and applies this function to it's DOM tree (and outputs the result) would be really great. Thanks, Andreas -- You now have Asian Flu.

4 12

[lxml-dev] swig_sources problem with Pyrex
by Stefan Behnel 05 Mar '06

05 Mar '06

one for the archives ... Paul Everitt wrote: > Stefan Behnel wrote: >> Paul Everitt wrote: >>> I'm stuck on compiling the trunk (the swig_sources error) for OS X. >> >> Check if you have this line in Pyrex/Distutils/build_ext.py (line ~35) >> >> def swig_sources (self, sources, extension=None): > > I have: > > def swig_sources (self, sources): > if not self.extensions: > return Then change it. You may just as well use def swig_sources(self, sources, *otherargs): It doesn't matter. It's just there to allow either two or three arguments. Stefan

2 2

[lxml-dev] Updated parser API
by Stefan Behnel 04 Mar '06

04 Mar '06

Hi, I updated the parser API according to the discussions (and the proposal of Fredrik) that we had in November. It now uses an XMLParser class that simply builds the libxml2 parse options in the constructor. I also added a global function "set_default_parser" that globally sets the default parser (options), or resets them if the supplied parser is None. Although the internal implementation may change later on, I think it is better to have this API in place *now* (i.e. for 0.9), so that we can simply add more features (i.e. keyword arguments) later on without changing the API itself. Since we already discussed this, I applied it directly to the trunk. Note, however, that currently not all parse options are backed by test cases. I added one that tests namespace stripping (in the new file test_parser.py), but considering the fact that most of the functionality is implemented entirely by libxml2, I (lazily) thought it's sufficient to test that the API works in general. Stefan

2 3

[lxml-dev] Clean up of extension function implementation
by Stefan Behnel 02 Mar '06

02 Mar '06

Hi all, I did a lot of cleaning up of my code regarding extension functions and I hope it's now pretty close to 'ready for merging'. You can look at doc/extensions.txt in the scoder2 branch for some examples. One problem, however, remains: the first argument to extension functions, which previously contained the current XPath evaluator. I absolutely cannot see a reason for adding this argument to the call. The only usable thing in the evaluator is the 'evaluate(path)' method, but I wouldn't even bet on it being re-entrant, so I can only hope that no existing code actually uses it. I did not want to break any legacy code by happily changing the argument order of the call, so I just kept that argument in there and added a line in the documentation stating that it should not be used (reserved for future extensions :). The new implementation simply passes None. It looks a bit ugly that way, but, well, we /may/ still succeed in finding a use for it some time after lxml 1.0 ... Have fun, Stefan

2 1

[lxml-dev] extracting namespace prefix map dict
by Gerald John M. Manipon 02 Mar '06

02 Mar '06

Hi, Is there a way to extract a namespace prefix map from an etree _Element, i.e.: xmlString= <?xml version="1.0"?> <sciflo xmlns="http://genesis.jpl.nasa.gov/sciflo" xmlns:sfl="http://genesis.jpl.nasa.gov/sciflo" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ... </sciflo> and get a dict: nsmapDict={'_default': "http://genesis.jpl.nasa.gov/sciflo", 'sfl': "http://genesis.jpl.nasa.gov/sciflo", 'xsd': "http://www.w3.org/2001/XMLSchema", 'xsi': "http://www.w3.org/2001/XMLSchema-instance"} Currently I'm parsing the xml into a minidom and extracting this info. Any help is greatly appreciated. Thanks, Gerald

2 3

lxml - The Python XML Toolkit March 2006