Mailman 3 October 2005 - lxml - The Python XML Toolkit

[lxml-dev] [PATCH] element parent access through Element.getparent()
by Stefan Behnel 06 Nov '05

06 Nov '05

Hi! Here's a little patch that adds a getparent() method to elements. It is missing from the ElementTree API, but libxml (obviously) provides it, so its trivial to expose it to the public API. Hoping for integration, Stefan

4 10

[lxml-dev] PATCH for formatting XML output
by Patrick Wagstrom 04 Nov '05

04 Nov '05

Hi, I'm a bit new to the project, but had a need to nicely format the output form lxml. Also, I have a need to leave the <?xml version="1.0"?> header at the top. So, I made a few changes to the write procedure. There are now two more arguments that can be called: format=0/1 (0 = default) whether or not the output should be pretty printed strip=0/1 (1 = default) whether or not the xml document definition should be stripped when using us-ascii or utf-8 encoding. I've attached the patch to this email. --Patrick

3 8

[lxml-dev] Work on branch "lxml-scoder1"
by Stefan Behnel 03 Nov '05

03 Nov '05

Stefan Behnel wrote: > I commited my original (final) patches one after the other, so you should now > have a trace of the changes. As I said, most of them do not depend on each > other, so each revision adds only the new features. > > The commited patches are: > (r18893) MANIFEST.in to enable setup.py targets like bdist_rpm > (r18894) _Element.getparent() > (r18895) SAX input and output of ElementTrees > > The next patch was made up by two, so I commited them separately: > (r18896) variable support in XPath expressions > (r18898) XPath class to support compiled expressions I forgot to say that these two depend on each other. > Then: > (r18899) support for namespace classes (r18903) incorporates a change from patch in 18899: I removed the class registry from ElementTree to keep it only at module level. This is actually more of a preparation for (r18907), where I saw that it doesn't really make sense to keep that functionality in _ElementTree. The next one is independent of the other patches: (r18904/5) (fix for a) fix for the bug reported by Carlos Pita And finally, I applied my big final patch that does the restructuring for ElementTree compliance. I first applied a partial patch with the test cases that compare ElementTree and etree to motivate the change. That's in (r18906). (r18907) contains the changes. It is so big because the structural modification required a significant bit of refactoring to adapt the rest of the implementation to the semantic changes. This revision passes the original test cases as well as the ones added in (r18906). I cc-ed the mailing list as I would really appreciate it if other people could test this branch, especially the final modifications. I'm specifically concerned about memory handling and this kind of stuff. There are not really any test cases for this, but I guess they are rather tricky to write. So please, test! :) For the volunteers: svn co http://codespeak.net/svn/lxml/branch/scoder1 lxml-scoder1 gives you a checkout of my branch into the directory lxml-scoder1. Stefan

3 4

[lxml-dev] Pyrex officially supports gcc4
by Olivier Grisel 03 Nov '05

03 Nov '05

http://comments.gmane.org/gmane.comp.python.announce/5559 That will make it easier to build lxml on recent linux and MacOSX platforms. -- Olivier

4 5

[lxml-dev] a patch for setup.py when libxml2 and libxslt are built to separate dir
by Trent Mick 03 Nov '05

03 Nov '05

Hello, I'm just starting to play with lxml and am quite pleased with it so far. Thank you for creating it. I have a small patch for setup.py that, if people think is reasonable, I'd like to see applied to lxml repo. Although probably not typical, one can build libxml2 and libxslt to separate directories. Say something like this: ~/opt/libxml2-2.6.22/... ~/opt/libxslt-1.1.15/... In that situation libxml2's "xml2-config" does not know how to return the proper compilation and link flags for both libxml2 and libxslt. However, libxslt (which depends on libxml2, of course) knows how: $ xml2-config --cflags -I/Users/trentm/opt/libxml2-2.6.22/include/libxml2 $ xslt-config --cflags -I/Users/trentm/opt/libxslt-1.1.15/include -I/Users/trentm/opt/libxml2-2.6.22/include/libxml2 My patch (see attached) changes guess_dirs() to use xslt-config. What do you think? Trent -- Trent Mick trentm(a)gmail.com

2 2

[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] Re: New Patch for lxml
by Stefan Behnel 26 Oct '05

26 Oct '05

Hi! Martijn Faassen wrote: > Stefan Behnel wrote: >> I commited my original (final) patches one after the other, so you >> should now >> have a trace of the changes. As I said, most of them do not depend on >> each other, so each revision adds only the new features. > > They do need to be mergeable separately, as it's unlikely I'll merge all > your changes as-is in one go. Perhaps with the revision numbers you list > this is possible. Anyway, I'll review things first and let you know what > I can do, but it's going to take a bit of time. I applied the patches in the order "trivial and should be in" to "pretty huge and worth discussing". And unless mentioned otherwise, they *should* all apply to the trunk cleanly. If one of them doesn't and you think it should be applied on its own, please tell me, I may be able to create a clean patch from the respective revision. Stefan

1 0

[lxml-dev] New Patch for lxml
by Stefan Behnel 22 Oct '05

22 Oct '05

New version of my patch, now incorporating the fix for the bug that Carlos' example triggered. Stefan

1 0

[lxml-dev] fromstring and encoding (a bug?)
by Carlos Pita 22 Oct '05

22 Oct '05

Hi! I'm having troubles when trying to parse xml from a string with iso-8859-1 encoded contents. Consider for example this test script: testxml = file("/tmp/test.xml", "w") testxml.write( """<?xml version="1.0" encoding="ISO-8859-1" ?> <root>\xfa</root>""") testxml.close() from lxml import etree print "%r" % etree.parse("/tmp/test.xml").getroot().text # => u'\xfa' print "%r" % etree.fromstring(file("/tmp/test.xml").read().decode("iso-8859-1")).text # => u'\xc3\xba' print "%r" % etree.fromstring(file("/tmp/test.xml").read()).text # => UnicodeDecodeError Here \xfa is the latin-1 u acute char. In the last three lines: 1) It's read from a document file with the correct encoding in its header. The output is: u'\xfa'. Right. 2) It's read from an unicode string decoded from that file via iso-8859-1 codec. The output is: u'\xc3\xba'. Wrong. 3) It's read from a raw string with that file contents. An UnicodeDecodeError is raised. Right? Wrong? Note that in the second case the input unicode string seems to be encoded to utf-8 at first and then decoded again but using the iso-8859-1 codec instead. So at the end not only its encoding but -worst- its contents are modified. (One quick fix would be to encode that output to latin-1 and then redecode again to unicode via utf-8.) Is that a bug? I can't figure myself another way of using fromstring than passing it a raw string with a correct header (which fails with an exception as in 3) or passing it an unicode string correctly decoded from the original (which fails as in 2). Best regards, Carlos ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar

2 2

[lxml-dev] fromstring and encoding (a bug?)
by Carlos Pita 21 Oct '05

21 Oct '05

Hi! I'm having troubles when trying to parse xml from a string with iso-8859-1 encoded contents. Consider for example this test script: testxml = file("/tmp/test.xml", "w") testxml.write( """<?xml version="1.0" encoding="ISO-8859-1" ?> <root>\xfa</root>""") testxml.close() from lxml import etree print "%r" % etree.parse("/tmp/test.xml").getroot().text # => u'\xfa' print "%r" % etree.fromstring(file("/tmp/test.xml").read().decode("iso-8859-1")).text # => u'\xc3\xba' print "%r" % etree.fromstring(file("/tmp/test.xml").read()).text # => UnicodeDecodeError Here \xfa is the latin-1 u acute char. In the last three lines: 1) It's read from a document file with the correct encoding in its header. The output is: u'\xfa'. Right. 2) It's read from an unicode string decoded from that file via iso-8859-1 codec. The output is: u'\xc3\xba'. Wrong. 3) It's read from a raw string with that file contents. An UnicodeDecodeError is raised. Right? Wrong? Note that in the second case the input unicode string seems to be encoded to utf-8 at first and then decoded again but using the iso-8859-1 codec instead. So at the end not only its encoding but -worst- its contents are modified. (One quick fix would be to encode that output to latin-1 and then redecode again to unicode via utf-8.) Is that a bug? I can't figure myself another way of using fromstring than passing it a raw string with a correct header (which fails with an exception as in 3) or passing it an unicode string correctly decoded from the original (which fails as in 2). Best regards, Carlos ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar

1 0