Mailman 3 January 2015 - 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

Generating code from schema
by Charlie Clark 29 Jan '15

29 Jan '15

Hi, just a quick question about what you can and cannot do with lxml's schema support. In openpyxl we're moving towards a 1:1 implementation of the underlying schema. lxml.objectify isn't directly an option for two reasons: lxml is an optional dependency and there are cases where we'd definitely run out of memory. Instead we're using descriptors to enforce type definitions. This means a little more code but now that it seems to be working well I was thinking whether we could automate some of the process. I've looked at some of the existing XSD to Python generators but the generated code is far from what I'd like to have. Can we use the lxml schema support for anything other than validation? ie. can I query a schema object for a particular definition? Or is the best approach to parse the XSD files directly and work through the definitions with a mapping? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226

4 13

etree.xmlfile shadows exceptions thrown by output
by D.H.J. Takken 28 Jan '15

28 Jan '15

Hello, I use etree.xmlfile and a coroutine to generate XML into a file-like object that does post-processing on the XML data. Now, if I use the send() method to produce invalid XML data, the post-processor throws an exception. Here, I see a little problem: No matter what exception is thrown by the post-processor, the send() method always generates a generic IO exception. Apparently, lxml catches any exception thrown by the file-like object and produces a generic IO exception in stead. This means that there is no way to know what exactly went wrong in the post-processor. That information is lost. Inside the coroutine, I *do* get the original exception from the post-processor, but doing the error handling there is kind of ugly. Is there a better way to solve this problem? Thanks a lot!

2 6

moving all attributes from one element to another
by Martin Mueller 27 Jan '15

27 Jan '15

I want to move all attributes of an element to another element. If the attributes of elements x are x.attrib and attributes = x.attrib, is there a single command that says "take the attribute dictionary of x and attach it to y"? Or do I have to use the .set method for each individual attribute? MM

4 5

Re: [lxml] Possible bug with etree.XPath
by Alex Vincent 22 Jan '15

22 Jan '15

> It's not about the lxml devs. The XPath compiler and engine are implemented > by libxml2 and allow you to define your own XPath functions and even > replace existing ones. Ahh, that's what I didn't know. From reading the lxml docs, behavior in libxml2 is not considered a lxml bug. That's why I came to this mailing list: for clarification. :-) Thanks, both of you! -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001

1 0

Re: [lxml] Possible bug with etree.XPath
by Alex Vincent 22 Jan '15

22 Jan '15

> An error will only manifest when actually evaluating the > XPath: > ... > Note that you won't run into the error when the XPath predicate's not > applied i.e. contains() is not even called: > ... > So calling with the wrong arg number is an XPath runtime, not an XPath > compile time error. > > Indeed you wouldn't know if there's an error or not at compile time: > That's what I was asking about: determining at compile time, if practical. We do our XPath lookups inside a browser, but we can read the scripts that provide the XPaths with a Python script. I understand if the lxml devs do not consider this a bug, but it would be helpful for us. I recognize your point about Python having the same behavior, except that the set of XPath 1.0 functions and their arguments are well-defined. -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001

2 1