[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Marco Sulla added the comment: Thanks, but telling the truth: 1. I just not use SubElement, even if it's more convenient. I just create an Element and I append to the parent one. It's much more clear IMHO 2. I do not use `fromstring` and all its friends. It was just a suggestion 3. I alread

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Serhiy Storchaka added the comment: Closed since this issue contains several unrelated propositions, most of which have been rejected. If you want to add helper functions for comparing Elements (shallow and deep, with and without taking and order of attributes to account, with and without i

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Marco Sulla added the comment: @rhettinger: "Deprecating [...] just cause disruption to existing, deployed code" How? Deprecating is used just to maintain intact the already existing code... "Please do not go down of the path of making yourself the arbiter of what is Pythonic or standard.

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Raymond Hettinger added the comment: Macro, we appreciate your sentiments. Please consider this module has been around for a long time and that others aren't reacting to the API the same way you are. Deprecating SubElement, fromstringlist() and tostringlist() because you don't like them wi

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Marco Sulla added the comment: @scoder: 1. the fact that == does not traverse the Element is IMHO unpythonic and non-standard. A trivial example: >>> a = {1: {2: 3}} >>> b = {1: {2: 3}} >>> a == b True You can have a dictionary complicated as you want, but if they have the same structure,

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Stefan Behnel added the comment: Right. If you want to compare XML trees for equality, either write your own deep-tree comparison function, or use something like doctestcompare, or use a C14N serialisation (which is now part of Py3.8). Whichever suits your needs. https://github.com/lxml/lxml

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Serhiy Storchaka added the comment: In some applications the order of attributes matters, and in others it does not. So the equality check is application dependent. -- nosy: +serhiy.storchaka ___ Python tracker

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Stefan Behnel added the comment: FWIW, deep traversing an XML tree on an operation as simple as "==" seems excessive. To me, object identity comparison seems the most sensible behaviour of "==" on Element objects. (It's not "complicated to implement", but rather can be very expensive to exec

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Raymond Hettinger added the comment: By default, all objects compare based solely on identity. Are you making a feature request for Element objects to grow a recursive equality test that includes attributes regardless of order and disregards processing instructions and comments? What is you

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

Change by Karthikeyan Singaravelan : -- nosy: +eli.bendersky, scoder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

New submission from Marco Sulla : Currectly, even if two `Element`s elem1 and elem2 are different objects but the tree is identical, elem1 == elem2 returns False. The only effective way to compare two `Element`s is ElementTree.tostring(elem1) == ElementTree.tostring(elem2) Furthermore, from