Mailman 3 October 2009 - lxml - The Python XML Toolkit

[lxml-dev] lxml has its page on launchpad
by Stefan Behnel 11 Apr '23

11 Apr '23

Hi all, I added the lxml project to launchpad, the Ubuntu Bug-Tracker. It also has a FAQ engine and a couple of other goodies. https://launchpad.net/lxml It's easy to sign up for launchpad, BTW, no 90%-footnotes-contract. Have fun, Stefan

9 9

[lxml-dev] Checking whether a node is a comment/element
by Geoffrey Sneddon 10 Apr '23

10 Apr '23

Hi, What's the best way to check whether a given node is a comment or an element? For the former, I'm currently using isinstance(node, etree._Comment), which is rather obviously sub-optimal. -- Geoffrey Sneddon <http://gsnedders.com/>

6 6

[lxml-dev] Reparenting a node
by Lawrence Oluyede 30 Jan '23

30 Jan '23

I have a doc A and a doc B, I'd like to put a node extracted from A in the document B but I always get a ValueError: ValueError: Element is not a child of this node. I didn't find any "setparent" in the API. How can I do this? -- Lawrence, oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair

3 2

[lxml-dev] lxml 2.0.5 released
by Stefan Behnel 11 Jan '23

11 Jan '23

Hi all, lxml 2.0.5 is on PyPI. This is a bug-fix-only release of the stable 2.0 series. Have fun, Stefan 2.0.5 (2008-05-01) Bugs fixed * Resolving to a filename in custom resolvers didn't work. * lxml did not honour libxslt's second error state "STOPPED", which let some XSLT errors pass silently. * Memory leak in Schematron with libxml2 >= 2.6.31.

3 4

[lxml-dev] Building LXML Trunk
by Sidnei da Silva 31 Aug '22

31 Aug '22

Hi, I've tried to build lxml from trunk today, on Win32. Got the following error: src\lxml\etree.c(880) : error C2059: syntax error : ')' src\lxml\etree.c(881) : error C2059: syntax error : ')' src\lxml\etree.c(882) : error C2059: syntax error : ')' src\lxml\etree.c(883) : error C2059: syntax error : ')' Any clue? Smells like a Pyrex issue? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214

4 4

[lxml-dev] XPath optimization troubles.
by John Krukoff 28 Nov '09

28 Nov '09

Hello, I expect this is properly a libxml2 question, but it's weird enough I wanted to check here first to make sure that lxml isn't effecting the results. I have equivalent XPath expressions, one using prefixes to do the selection, and one using namespace-uri to do the check. The namespace-uri version consistently runs 2-3x faster on a range of test data, and I have no idea why. Here's the prefix version: > '//@gizmo:*/parent::*[ not( self::gizmo:* ) ]' And here's the namespace-uri version: > '//@*[ namespace-uri( ) = "%(gizmo)s" ]/parent::*[ namespace-uri( ) != "%(gizmo)s" ]' % namespaces I'm running these as compiled expressions using etree.XPath( ..., namespaces = namespaces ), if that makes a difference. Any hints? Or a faster XPath to do the same thing for the ambitiously bored? -- John Krukoff <jkrukoff(a)ltgc.com> Land Title Guarantee Company

2 2

Re: [lxml-dev] Handling processing instructions
by Chuck Bearden 09 Nov '09

09 Nov '09

On Wed, Oct 28, 2009 at 4:21 AM, Emanuele D'Arrigo <manu3d(a)gmail.com> wrote: > 2009/10/27 Chuck Bearden <cfbearden(a)gmail.com> >> >> On Tue, Oct 27, 2009 at 1:25 PM, Emanuele D'Arrigo <manu3d(a)gmail.com> >> wrote: >> > 1) short of iterating from the root element using repeatedly >> > getprevious(), >> > is there a way to obtain the processing instructions that are listed >> > before >> >> It is possible via XPath: >> >>> xmlTree.getroot().xpath('preceding-sibling::node()') > > Hi Chuck, thanks for your help! > > How is the xpath approach above different from: > > xmlTree.getRoot().getprevious() > > ? Evidently I mis-typed or mis-read the first time I tried the ElementTree way of getting a PI that precedes the root element. The obvious ElementTree way does indeed work. My mistake. >>> from lxml import etree >>> from StringIO import StringIO >>> xmlString = '''<?xml version="1.0"?> ... <?version 1.3?> ... <root> ... <branch> ... <leaf/> ... </branch> ... </root>''' >>> xmlTree = etree.parse(StringIO(xmlString)) >>> xmlTree.getroot().xpath('preceding-sibling::node()') [<?version 1.3?>] >>> xmlTree.getroot().getprevious() <?version 1.3?> >>> > And would I be correct in saying one would still need to iterate "upward" to > find the very first processing instruction? I guess I think of .getprevious() and the preceding-sibling XPath axis as horizontal rather than vertical, so I would say that you need to recur or iterate "backwards" to get all nodes preceding the root element. >>> from lxml import etree >>> from StringIO import StringIO >>> xmlString = '''<?xml version="1.0"?> ... <?first PI?> ... <?version 1.3?> ... <root> ... <branch> ... <leaf/> ... </branch> ... </root>''' >>> xmlTree = etree.parse(StringIO(xmlString)) >>> xmlTree.getroot().xpath('preceding-sibling::node()') [<?first PI?>, <?version 1.3?>] >>> xmlTree.getroot().getprevious() <?version 1.3?> >>> xmlTree.getroot().getprevious().getprevious() <?first PI?> >>> xmlTree.getroot().getprevious().getprevious().getprevious() >>> Chuck

3 4

[lxml-dev] Fun with unicode errors
by Praktikant3 - SAG 07 Nov '09

07 Nov '09

Hi, Maybe you have an idea what could be happening here, otherwise I will (try to) come back with a more complete example. For now I have this small code excerpt that behaves strangely: (isinstance(output_xml, lxml.etree._Element) is True) # The two ET.tostring() invocations below, (1) and (2), show the # following behaviour: # (1) "works" (UnicodeDecodeError about el.text after (2)) # (1) (2) "works" (UnicodeDecodeError about el.text after (2)) # (2) does not work, lxml.etree.SerialisationError: IO_ENCODER about ET.tostsring() (2) ET.tostring(output_xml) # (1) # Make pretty-printing work by removing unnecessary whitespace: for el in output_xml.iter(): ET.tostring(el) # (2) if len(el) and el.text and not el.text.strip(): el.text = None if el.tail and not el.tail.strip(): el.tail = None (1) and (2) are commented out to run them in the different combinations discussed. If you have a hint about what might be the issue there, I'd be very glad to hear it. I'm using this code on WinXP SP3, Python 2.6.4, lxml 2.2.2 (pre-compiled package). Expected behaviour would be to run without raising any exception in any of the runs. Something about output_xml changed, as this code snipped used to work. Thanks, Felix

3 5

[lxml-dev] 2.2.2 binary egg for Mac OS X 10.6
by Martin Aspeli 02 Nov '09

02 Nov '09

Hi, We have binary eggs for Python 2.4, 2.5 and 2.6 on Mac OS X 10.5. Unfortunately, we don't have them for 10.6 (Snow Leopard), and the 10.5 egg doesn't work on 10.6 (it crashes on startup). Is there any chance we could have 10.6 eggs? If there are reliable build instructions, I can help build them. Cheers, Martin

2 3

[lxml-dev] lxml 2.2.3 released
by Stefan Behnel 31 Oct '09

31 Oct '09

Hi all, I just released a new bugfix-only release to PyPI: lxml 2.2.3. It fixes many bugs, some of which are critical or at least annoying, so updating is generally recommended and should mostly be a drop-in for 2.2.x users. Have fun, Stefan 2.2.3 (2009-10-30) Bugs fixed * The resolve_entities option did not work in the incremental feed parser. * Looking up and deleting attributes without a namespace could hit a namespaced attribute of the same name instead. * Late errors during calls to SubElement() (e.g. attribute related ones) could leave a partially initialised element in the tree. * Modifying trees that contain parsed entity references could result in an infinite loop. * ObjectifiedElement.__setattr__ created an empty-string child element when the attribute value was rejected as a non-unicode/non-ascii string * Syntax errors in lxml.cssselect could result in misleading error messages. * Invalid syntax in CSS expressions could lead to an infinite loop in the parser of lxml.cssselect. * CSS special character escapes were not properly handled in lxml.cssselect. * CSS Unicode escapes were not properly decoded in lxml.cssselect. * Select options in HTML forms that had no explicit value attribute were not handled correctly. The HTML standard dictates that their value is defined by their text content. This is now supported by lxml.html. * XPath raised a TypeError when finding CDATA sections. This is now fully supported. * Calling help(lxml.objectify) didn't work at the prompt. * The ElementMaker in lxml.objectify no longer defines the default namespaces when annotation is disabled. * Feed parser failed to honour the 'recover' option on parse errors. * Diverting the error logging to Python's logging system was broken.

1 1