Mailman 3 February 2007 - lxml - The Python XML Toolkit

[lxml-dev] nscleanup branch merged: better namespace handling in lxml
by Stefan Behnel Feb. 25, 2007

Feb. 25, 2007

Hi, I finally found the time to take a second look back at the nscleanup branch. I found that the reason for one of the test failing was not even related to the changes on the branch, so I just merged it into the trunk. So, now lxml has its own implementation for namespace cleanup when moving elements between trees. The main problem that this is meant to solve is the redundant redeclaration of namespaces that already exist in the target tree. This should now be avoided. I also expect it to be faster than the previous version - although I haven't done the benchmarks yet to prove it. So, please, everyone who had problems with this kind of bug in the past: please check if this problem is gone for your application. And everyone else who wants to help out: please check out the current trunk, build it and test it with your application to see if it still works as expected. This is a change in a rather critical place, so I'd like to have it tested before releasing it to the masses. I'm planning to release a beta version of 1.3 soon, so that it becomes easier to test. But I'd be happy to have some feedback on this before hand. Have fun, Stefan

2 2

[lxml-dev] pretty-printing
by Albert Brandl Feb. 24, 2007

Feb. 24, 2007

Hi! I've posted a question about pretty-printing some time ago. Now I finally found the time to construct an example. The problem occurs with the following code: nsmap = dict (foo="http://foo.org", bar = "http://bar.org") e = Element("{http://foo.org}somefoo", nsmap = nsmap) s = Element("{http://bar.org}somebar", nsmap = nsmap) e.append(s1) et = ElementTree(e) et.write("foo.xml", pretty_print = True) This code creates the following XML file: <foo:somefoo xmlns:foo="http://foo.org" xmlns:bar="http://bar.org"> <bar:somebar xmlns:foo="http://foo.org" xmlns:bar="http://bar.org"/> </foo:somefoo> The problem is that "bar:somebar" redundantly declares the namespaces for "foo" and "bar", which affects both the readability and the size of the XML file. If the element "s" is appended to "e" by using the SubElement function instead of "append", the content of the XML file looks like I'd expect: <foo:somefoo xmlns:foo="http://foo.org" xmlns:bar="http://bar.org"> <bar:somebar/> </foo:somefoo> Is this a known bug? Thanks & best regards, Albert Brandl

4 5

[lxml-dev] side menu for HTML pages
by Stefan Behnel Feb. 23, 2007

Feb. 23, 2007

Hi all, following the remark of Matthew Cruickshank, I added a simple side menu to the HTML pages. It doesn't use the most sophisticated menu builder tool ever, but it uses lxml (obviously a great plus) and does more or less what you'd expect. As usual, the site is here: http://codespeak.net/lxml/dev/ I'd be glad if someone could play with the CSS a bit more, BTW. The layout is definitely sub-optimal and things like hover-uncover effects would be nice to have. :) Have fun, Stefan

2 1

[lxml-dev] help for uses debugging XSLT
by Dennis Allison Feb. 21, 2007

Feb. 21, 2007

When an error occurs, the traceback if for the lxml program detecting it. The traceback is not very useful when the error is with the XML and/or XSL data. Is there a good way to grab the data context in which the error occured. --

2 1

[lxml-dev] AssertionError double registering proxy
by Holger Joukl Feb. 21, 2007

Feb. 21, 2007

Hi, lately I've been running into such problems: 2007/01/23 13:22:02:all2all_MainThread:ERROR: cache[msg] = list(msg.getiterator()) 2007/01/23 13:22:02:all2all_MainThread:ERROR: File "etree.pyx", line 1562, in etree.ElementDepthFirstIte rator.__next__ 2007/01/23 13:22:02:all2all_MainThread:ERROR: File "etree.pyx", line 1207, in etree._elementFactory 2007/01/23 13:22:02:all2all_MainThread:ERROR: File "proxy.pxi", line 28, in etree.registerProxy 2007/01/23 13:22:02:all2all_MainThread:ERROR:<ThreadedQueue name='TQ_normal'>: AssertionError: double regi stering proxy! I strongly suspect this is a threading-related problem as it occurs in a multithreaded test program. I'm also able to fix this if any thread copy.deepcopy()'s all incoming Elements before doing anything with them (the threads basically dispatch from Queues where other threads have put Elements into). Hence my question: - Am I doing something nasty here which is pretty much forbidden (I know I will have to copy my Elements anyway, as my threads will want to modify them) - and/or should lxml guard the element proxy registration ? All the best, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. Landesbank Baden-Württemberg Anstalt des öffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim

2 7

[lxml-dev] documentation split
by Stefan Behnel Feb. 21, 2007

Feb. 21, 2007

Hi all, Martijn's recent call got me started on a major restructuring of lxml's documentation. I mainly split up the humongous api.txt for now and did a bit of rewriting in main.txt. The split might have left some paragraphs without context, so I wouldn't mind having somebody take a look over them. The current version is available from http://codespeak.net/lxml/dev/ Any help, comments and (preferably) patches against doc/*.txt are very welcome! Stefan

1 0

[lxml-dev] [objectify] __setText method not usable from python classes
by Holger Joukl Feb. 21, 2007

Feb. 21, 2007

Hi, I've experimented with the ObjectifiedDataElement.__setText method a bit and found that it is unusable from within python data elements due to Python's name mangling. E.g. you can't have s.th. like def _init(self): self.__setText("try this") or def _init(self): ObjectifiedDataElement.__setText(self, "try this") This results in AttributeError: type object 'objectify.ObjectifiedDataElement' has no attribute '_DatetimeElement__setText Confusingly __setText has no notion of being private when used from the outside, you can well do >>> objectify.ObjectifiedDataElement.__setText(msg.d, "1900") >>> Maybe use just a single leading underscore and rename it to _setText? Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. Landesbank Baden-Württemberg Anstalt des öffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim

2 1

Re: [lxml-dev] [objectify] __MATCH_PATH_SEGMENT regexmodificationsuggestion
by Holger Joukl Feb. 21, 2007

Feb. 21, 2007

Hi, just noticed this has probably gone down and wanted to bring it up once more: I suggest to loosen the __MATCH_PATH_SEGMENT regex a little to care for more possible element names, which are sometimes outside of my control. Currently ObjectPath chokes on paths like 'root.a-x.a-y'. While such names are often inconvenient at best I found that python itself is quite non-restrictive wrt attibute names: python2.4 Python 2.4.3 (#2, Nov 20 2006, 16:26:48) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... pass ... >>> setattr(Foo, 'a-b', "hmm") >>> Also, such names are actually allowed: >>> etree.tostring(etree.fromstring("""<a-a><b>34</b></a-a>""")) '<a-a><b>34</b></a-a>' >>> "Holger Joukl" <Holger.Joukl(a)LBBW.de> schrieb am 02.01.2007 14:56:05: > "Holger Joukl" <Holger.Joukl(a)LBBW.de> schrieb am 29.12.2006 16:16:12: > > > I suggest to loosen the __MATCH_PATH_SEGMENT regex a little > > [...] > > Sorry that was too loose as it destroys the correct matching of the > index part; it should read > > __MATCH_PATH_SEGMENT = re.compile( > r"(\.?)\s*(?:\{([^}]*)\})?\s*([^.{}\[\]]+)\s*(?:\[\s*([-0-9]+)\s*\])?", > re.U).match > > (Changed: (([^.{}\[\]]+) replaces (\w+)) Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. Landesbank Baden-Württemberg Anstalt des öffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim

2 1

[lxml-dev] objectify.fromstring vs etree.fromstring in threaded environment
by Holger Joukl Feb. 21, 2007

Feb. 21, 2007

Hi, just a quick question: Can it be problematic to use objectify.fromstring() in a threaded environment? If I'm not getting it wrong, etree.fromstring() replicates (copies) the default parser for each thread context, whereas objectify.fromstring just uses its default parser regardless of threading contexts. Ain't that dangerous wrt to what the FAQ says? Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. Landesbank Baden-Württemberg Anstalt des öffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim

2 1

Re: [lxml-dev] lxml extensions (fwd)
by Dennis Allison Feb. 20, 2007

Feb. 20, 2007

Configuration details: Ubuntu 6.06, Python 2.4, lxml 1.1.2. I am using the lxml XSLT feature to transform an XML specification into a collection of files for use in a web application. I need some beyond the usual XSLT and XPATH capabilities and so have been trying to use the python extension facilities. I am following the "APIs specific to lxml" and the "Extension functions for XPath and XSLT" portions of the docs. The XSLT processing follows the published pattern from lxml import etree from StringIO import StringIO # python extension function def func(dummy): return 'some result' # namespace setup ns = etree.FunctionNamespace('http://mydomain.com/functions') ns['func'] = func ns.prefix = 'nf' # create XSLT transform and apply to doc xslt_doc = etree.parse StringIO('xslt_file','r').read()) transform = etree.XLST(xslt_doc) doc = etree.parse(StringIO('xml_file','r').read()) result = transform(doc) print str(result) My test XSLT file contains an XPath expression of the form <xsl:value-of select="nf:p()" /> When applied, the function does not seem to be invoked. Some experimentation using parameters cause me to suspect that nf:p resolves to None or the empty string. I presume the problem is a namespace problem, but it's unclear how to resolve it from the documentaton. I am guessing that I need to pass the namespace object to etree.XSLT when I create the transform() but I was unable to find a hint in the docs. And, while Google is my friend, it did not locate help in this case. It did turn up an exchange on the mailing list with a similar problem, which remains unresolved. Any assist would be appreciated. Does anyone have a working example of XSLT processing which includes execution of python extensions.

3 6