Mailman 3 June 2018 - 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

Re: [lxml] Default parser with/without no_network
by Duthie, Roger J.A. 26 Jun '18

26 Jun '18

Hello again, An update on my attempts to work out the behaviour of the parsers/resolvers. This thread (Question 2) involved the validation of XML against a schematron and the apparent inability of the parser to resolve remote resources. It seemed that my [real world] example was throwing up a few issues. Going back to my example code and output: https://gist.github.com/rogie-bas/e157501d12cff8ac0aafc0cc120ce8dc (The link in the previous email may have been broken, because the fullstop was added to the URL, the above will hopefully work without modification!) The first test logging (base resolver, no_network=True) shows that the validation fails with an XSLTApplyError, due to a resource not be resolvable (..../gmxCodeLists.xml). Confusingly, it doesn't seem to be the first one on the list of resources that the code has tried to resolve. However, the behaviour is different if no_network=False. It seems that the resource that the code chokes on is a different one (.../SDN:L11::D08). I may have a tentative reason why on this (based on empirical evidence). I broke my schematron file down into single patterns which I deemed targetting parts of the XML file containing various remote resources. This way I could try resolving the various resources with the various parsers, with no_network = {True | False}. The gmxCodeLists.xml resource is not resolved with the base resolver if no_network=True, but is when no_network=False. The resolution of the other resource (SDN:L11::D08) never happens. If using resolve_filename() method rather than the base resolver, the error is different: an OSError is thrown for these resources, as if the resource was deemed to be a file system resource, instead of a remote resource; however, the gmxCodeLists.xml is resolved correctly. The resolver I created using the Requests package doesn't have a problem with this resource. I've now got a hunch that this is perhaps because the URI for this problematic resource is a redirect (checking with curl -IL, shows that it is a 302/301/200 chain). I can't currently rule out that there is something else about this resource that makes it unresolvable, but when I change the references to this resource, to point at the redirect, the validation completes. My next task is to create some simple external resources with redirects. Is any of this behaviour expected? - no_network has no effect apart from with the base resolver - redirects are unresolvable by the base resolver and resolve_filename base resolution - resolution seemingly going ahead (successive calls to the resolver methods without error - see example test #1 in the linked logging), but really it's not Any insights greatly appreciated. Roger ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ________________________________

2 2

lxml and pypy
by Martin Mueller 24 Jun '18

24 Jun '18

Would lxml run faster with pypy or is it irrelevant because most of the work is done by libxml?

3 2

Re: [lxml] lxml https question
by Stefan Behnel 22 Jun '18

22 Jun '18

[Bringing this back to the mailing list] Anrik Drenth schrieb am 22.06.2018 um 01:43: > Anrik Drenth schrieb am 17.06.2018 um 04:40: >> The weird thing is it loads A OK, using https, in Oxygen. >> I believe that oXygen uses xerces rather than libxml2? >> >> I think the issue is with the schema(s) having various imports. lxml might be looking locally (on the actual machine) instead of looking in the directory for the url supplied. Have just confirmed this by saving all the needed xsd files locally and then calling the main XSD vi https. >> >> I tried changing the schemalocation i.e.: >> >> <xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" >> schemaLocation="xmldsig-core-schema.xsd" /> >> >> to this: >> >> <xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" >> schemaLocation="https://www.w3.org/2000/09/xmldsig" /> >> >> But this did not work. It's always better to provide an actual error message than to state a generic "does not work". The clearer you describe what you try and what the result is, the more likely it is that others spot the problem. > When I change the url in the below code from http to https the following error is displayed: > > lxml.etree.XMLSchemaParseError: Element '{http://www.w3.org/2001/XMLSchema}element', attribute 'ref': The QName value '{http://www.w3.org/1999/xhtml}div' does not resolve to a(n) element declaration., line 336 I'm a bit surprised that you get a validation error here. If any of the imported sub-schemas can't be found, you should get an error about that. Could you check if the "schema.error_log" contains any further warnings? > OS, software, and versions > ubuntu = 16.4 LTS > python = 2.7 > lxml = 4.2.1 > > Python Code > from lxml import etree > import urllib2 > schema_src_file = urllib2.urlopen('-- url ---') > schema_doc = etree.parse(schema_src_file) Did you also try "etree.parse('...url...')" ? Not sure if it makes a difference, but it's simpler, at least, and the problem here could be that libxml2 lacks information about where the schema originally comes from, so... > schema = etree.XMLSchema(schema_doc) > > What is interesting, for https, when I download and save all the supporting/imported xsd files to the local directory, the code with https works! > > http works with or without the supporting xsd files. > > The schemas, if needed, can be downloaded from https://files.secureserver.net/0shasWXjlDT4wT > [https://imagesak.secureserver.net/off/images2/icon_off_50_by_50.gif?v=7]<https://files.secureserver.net/0shasWXjlDT4wT> > > XSDSchemas.zip<https://files.secureserver.net/0shasWXjlDT4wT> > File shared through Online Storage > files.secureserver.net > > Apologies for the confusion regarding changing url references. In my many attempts to get https to work I tried many things. This included a suggestion I found on Google which said "in your main XSD if you do an import, change the schemaLocation=filename.xsd to schemaLocation=https://url/filename.xsd". I tried taht and it didnt work. > > Let me know if you need anything further. Stefan

1 0

Re: [lxml] Default parser with/without no_network
by Duthie, Roger J.A. 18 Jun '18

18 Jun '18

Hello all, An update: In testing the resolve_filename method when validating XML against the published standard's schematron, I found that a resolver using this method also has difficulties: a different ones to the default parser, but the same resource is implicated. The filename resolver seems to fail at the same point as a default resolver with no_network=True. Whether no_network is True or False does not seem to affect the behaviour of this resolve_filename resolver, however. I have update the Gist with two more tests using the filename resolver: https://gist.github.com/rogie-bas/e157501d12cff8ac0aafc0cc120ce8dc One other observation, it seems that this resolver is called twice for each resource lookup (cf., logging included with the Gist). Is that expected? I'm going to try getting a simple example written for this issue, to try to focus on what seems to work and what doesn't. Currently, on my list of suspects are: HTTP redirects and use of network; although neither of these completely fits as some resources appear to have been resolved despite being on the network or having been redirects. As always, any insights are appreciated. Roger ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ________________________________

1 0

Re: [lxml] Resolvers - What's going on here?
by Duthie, Roger J.A. 15 Jun '18

15 Jun '18

Update on this issue (Question 1): I've created a minimal example of the issue of the path construction issue when an import is used (test_1.tar.gz). In this example, the loss of the re-constructed path occurs with the <import>'d resource itself; the original example had this occurring with a resource <include>'d by the <import>'d resource, but the limitations of a portable example mean that the <import>'d resource has a relative link in the XML. I have looked at <include>'ing more resources from the first namespace (test_2.tar.gz) and found that this is not expanded properly either. So it seems that the first include/import works, but subsequent ones do not. This may simply be related to the reported bug here: https://bugs.launchpad.net/lxml/+bug/1568167 This bug report states the the base_url parameter does not work for the resolve_* methods. Incidentally, what's nice is that the resolve_filename method works as well as the default resolver for this example. I'll have to work on simplifying Question 2, to see if I have a solution already. Roger ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ________________________________

1 0