Mailman 3 August 2021 - 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

Tested value modified in validation error message
by Bob Kline 15 Jul '22

15 Jul '22

Before I file a ticket, I wanted to check here to find out if this is a known problem (I searched the bug tracker, but didn't see any matches). Our customer is using a commercial XML editor and the editor's implementation of the DOM API sometimes garbles whitespace inside text nodes when serializing XML documents for the document's xml property. This causes schema validation errors when we send that serialization off to be validated against the document type's schema using lxml. The problem we have run into with lxml is that the message property of the error object which comes back in the schema object's error_log has altered the value being validated. So, for example, if the text content of an element in the serialized DOM is "Processing\ncomplete" and the value it was supposed to match in the enumerated valid values is "Processing complete" then the message attribute for the corresponding object in the error_log has Element 'ProcessingStatusValue': [facet 'enumeration'] The value 'Processing complete' is not an element of the set {'Ready for English peer review', 'Ready for English scientific review', 'Ready for English OCCM review', 'Ready for Spanish peer review', 'Ready for Spanish OCCM review', 'Ready for publishing', 'Ready for translation', 'Processing complete'}. In effect saying "the value 'Processing complete' does not match the value 'Processing complete'." Took a very long time for us to figure out that the error message was wrong, and that it should have said ... The value 'Processing\ncomplete' is not an element of the set .... -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

4 10

West palm. Beach century village 33417
by siennarose29＠gmail.com 24 Aug '21

24 Aug '21

TextNow 9.01n ontrollerOnePane] open 15615309539 2021-08-18 17:45:11 DEBUG TextNow converso Nisch 5G [MinConlogcat_0_2021-08-18_20-42-... IE MessageViewFragment{dcc289d) (244142d1-476b-487d bcc6-7691fce5cff8)} 2021-08-18 17:45:11 TextNow DEBUG [MainControllerOnePane] Detaching previous fragment Conversations List Fragment{db4ff0e} (aee60ab2-76e3 48e1-9ade-508b30845f54) id=0x7f0a0374} 2021-08-18 17:45:11 DEBUG [MainControllerBase] commit FragmentTransaction: BackStackEntry{abb5112} TextNow 2021-08-18 17:45:11 TextNow DEBUG ainControllerOnePane] New back stack depth: 2 2021-08-18 17:45:11 DEBUG TextNow [TNFragmentBase] on FragmentViewCreated Listener not implemented 2021-08-18 17:45:11 TextNow DEBUG [MessageViewFragment] onCreate() called with: savedInstanceState = [null] 2021-08-18 17:45:11 DEBUG [MessageViewFragment] onCreate: found conversation for: Mike TextNow 2021-08-18 17:45:11 TextNow onPause () 2021-08-18 17:45:11 TextNow DEBUG [InStreamNativeAd] [SpamReportHelper] +15615309539 DEBUG Determining spam reporting state contact: 2021-08-18 17:45:11 DEBUG TextNow onDestroy() 2021-08-18 17:45:11 TextNow [InStreamNativeAd] [TextNow] DEBUG MessageViewFragment{dcc289d} (244142d1-476b-487d bcc6-7691fce5cff8) id=0x7f0a0374} onCreateView 2021-08-18 17:45:11 DEBUG TextNow Checked block state for a single 2021-08-18 17:45:11 DEBUG TextNow User should not see spam report [BlockedContactUtils] contact value [SpamReportViewModel] 2021-08-18 17:45:11 DEBUG [BlockedContactUtils] TextNow Checked block state for a single contact value 2021-08-18 17:45:11 DEBUG TextNow [MoPubKeywordUtils] MoPub keywords for unit 607e9f68526342818e85907f1bf8fcbc :m_app_version: 21.30.1.0,m_platform: android, m_gender: m, sdk: verizon, sdk: verizon:1.9.0, sdk: applovin_sdk, sdk: applovin_sdk: 9.14.8, sdk: admob_native, sdk:admob_native :20.0.0,sdk: facebook, sdk: facebook: 6.5.1, sdk: fyber, sdk : fyber: 7.8.3, sdk: ironsource, sdk: ironsource: 7.1.6, sdk: AmazonAdSDK, sdk: AmazonAdSDK: 9.1.0, sdk: Ogury, sdk: Ogury :5.0.5, sdk: smaato, sdk: smaato: 21.5.9, networktype: data 2021-08-18 17:45:11 DEBUG location TextNow Failed to [LocationUtils] rotriqu to 33%

1 0

Question - LXML compatibility with Python 3.9 on Linux (travis)
by Petr Hanák 18 Aug '21

18 Aug '21

LXML package states, that has minimal requirements on python - Requires: Python >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, != 3.4.* Based on what I see on Travis, it seems to me, that for python 3.9.x. the minimum stable LXML version is 4.3.x; is that expected? Sample log: Collecting lxml==4.2.6 Downloading lxml-4.2.6.tar.gz (2.4 MB) Building wheels for collected packages: lxml Building wheel for lxml (setup.py) ... error ERROR: Command errored out with exit status 1: command: /home/travis/virtualenv/python3.9.1/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-i7un6wlk/lxml_b3782dbd0b1b4611a75033d4ab809f51/setup.py'"'"'; __file__='"'"'/tmp/pip-install-i7un6wlk/lxml_b3782dbd0b1b4611a75033d4ab809f51/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-v441aa6c … … creating build/temp.linux-x86_64-3.9/src/lxml gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -I/usr/include/libxml2 -Isrc -Isrc/lxml/includes -I/home/travis/virtualenv/python3.9.1/include -I/opt/python/3.9.1/include/python3.9 -c src/lxml/etree.c -o build/temp.linux-x86_64-3.9/src/lxml/etree.o -w src/lxml/etree.c: In function ‘__Pyx_modinit_type_init_code’: src/lxml/etree.c:230310:32: error: ‘PyTypeObject {aka struct _typeobject}’ has no member named ‘tp_print’ __pyx_type_4lxml_5etree_Error.tp_print = 0; You can see the full logs and which version was installed sucessfully and which not on the compatibility build matrix here: https://app.travis-ci.com/github/SAP/python-pyodata/builds/233333488

2 2

Re: lxml.objectify interprets <x>1000_000</x> as int in Python>3.6 - should it?
by Holger.Joukl＠LBBW.de 13 Aug '21

13 Aug '21

> >> According to https://www.w3.org/TR/xmlschema-2/#integer 1000_000 is > >> not a valid integer literal. But it is for Python since 3.6. > >> > >> The magic lxml.objectify type lookup/annotation simple does int(s) > >> and interprets success as "shall be interpreted as int". > >> One could argue that - when parsing XML data - this is not the > >> right/sane/intuitive choice. Or is it? :-) <x>1000_000</x> is not an > >> integer in the XML world. > > > > Then we shouldn't make it one. It's unlikely that data gets passed > > through XML in Python syntax. We have the same for "True" and "False", > > which come out as str, not bool. And this applies to FloatElement as > > well, which uses > > float() as parser and thus also supports "_" in Py3.6+. > > > > I'll see what I can come up with. > > https://github.com/lxml/lxml/commit/83e6c031994d553b74991501c6cd85e3517fadd > 8 > > Stefan Great! Will check. Thanks, Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart HRA 4356, HRA 104 440 Amtsgericht Mannheim HRA 40687 Amtsgericht Mainz Die LBBW verarbeitet gemaess Erfordernissen der DSGVO Ihre personenbezogenen Daten. Informationen finden Sie unter https://www.lbbw.de/datenschutz.

1 0

lxml.objectify interprets <x>1000_000</x> as int in Python>3.6 - should it?
by Holger.Joukl＠LBBW.de 13 Aug '21

13 Aug '21

Hi, python2.7 -c 'from lxml import objectify; root = objectify.fromstring("<root><x>1000_000</x></root>"); print(root.x, type(root.x), type(root.x.pyval)); print(root.x.text, type(root.x.text)); print(objectify.dump(root))' ('1000_000', <type 'lxml.objectify.StringElement'>, <type 'str'>) ('1000_000', <type 'str'>) root = None [ObjectifiedElement] x = '1000_000' [StringElement] python3.6 -c 'from pytaf.objectify.xmsg import *; from lxml import etree, objectify; root = objectify.fromstring("<root><x>1000_000</x></root>"); print(root.x, type(root.x), type(root.x.pyval)); print(root.x.text, type(root.x.text)); print(objectify.dump(root))' 1000000 <class 'lxml.objectify.IntElement'> <class 'int'> 1000_000 <class 'str'> root = None [ObjectifiedElement] x = 1000000 [IntElement] According to https://www.w3.org/TR/xmlschema-2/#integer 1000_000 is not a valid integer literal. But it is for Python since 3.6. The magic lxml.objectify type lookup/annotation simple does int(s) and interprets success as "shall be interpreted as int". One could argue that - when parsing XML data - this is not the right/sane/intuitive choice. Or is it? :-) <x>1000_000</x> is not an integer in the XML world. Opinions if that should be changed, maybe switchable? Would it break things for you? Of course, Python 3.6 (and consequently this objectify behavior) is 5 years old now and nobody seemed bothered. Plus you can customize the default lookup mechanism anyway. Cheers, Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart HRA 4356, HRA 104 440 Amtsgericht Mannheim HRA 40687 Amtsgericht Mainz Die LBBW verarbeitet gemaess Erfordernissen der DSGVO Ihre personenbezogenen Daten. Informationen finden Sie unter https://www.lbbw.de/datenschutz.

2 2