Dr. Volker Jaenisch schrieb am 01.03.22 um 16:06:
To find the desired sibling the code loops over all childern and matches
(parentNamespace, propertyName) against them.
The correct operation of _findFollowingSibling should IMHO be:
Make a lookup on all children (with the python property name only). If one
match is found then return this match. If none or more than one match is
found then no answer is possible.
I see a major drawback with this behaviour, and that is non-local
dependencies. If you have this XML:
<a:root xmlns:a="A" xmlns:b="B">
<b:ch1/>
<b:ch2/>
</a:root>
then "root.ch1" would give you the first child. Great, so you use that in
your code. Now, someone decides to send you an input document that looks
like this:
<a:root xmlns:a="A" xmlns:b="B" xmlns:c="C">
<b:ch1/>
<b:ch2/>
<c:ch1/>
</a:root>
And your code will suddenly fail to find "root.ch1". Depending on what your
code does and how it does it, it may fail with an exception, or it may fail
silently to find the desired data and just keep working without it.
Note that the content of the XML file that your code is designed to process
did not change at all. It's just that some entirely unrelated content was
added, in a completely different and unrelated namespace. And it was just
externally added to the input data, or maybe just some tiny portion it,
without telling you or your code about it. Especially in places with
optional content, where different namespaces are already a little more
common than elsewhere, this is fairly likely to go unnoticed.
I find this kind of behaviour dangerous enough to restrict the "magic" in
the API to what is easy to understand and predict.
Stefan
_______________________________________________
lxml - The Python XML Toolkit mailing list -- lxml@python.org
To unsubscribe send an email to lxml-le...@python.org
https://mail.python.org/mailman3/lists/lxml.python.org/
Member address: arch...@mail-archive.com
