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

[Marco Sulla]

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 already copy/pasted from SO a function that serialize the Element. I do 
not want to waste time to do something that will be not used as 
`Element.__eq__()` implementation, as IMHO should be. 

See ya.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 
ignoring whitespaces, etc), feel free to open a separate issue.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marco Sulla]

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.  The other core devs in this conversation are highly 
experienced.  Insulting them or the Fredrik Lundh's existing API won't help 
matters"

I'm not insulting anyone, I just said *IMHO* it's not pythonic. 

I think the example of a tree created with a simple dictionary is a clear 
signal that Python, in the Guido's mind, was created with the intention that 
equality should check the content of the objects and not just the ids, as Java, 
for example, does, even for objects that must be traversed to see if they are 
equal to another one.

The fact you can check if two objects are equal using simply == is, _IMHO_, 
more elegant, simple and useful. The fact that == checks the ids is not useful 
at all, since I can do it with id(elem1) == id(elem2). So what's the purpose of 
== ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 will just cause disruption to existing, deployed code.  
You're about 15 years too late for a design discussion ;-)  That ship has 
sailed. 

Your proposal to add a new feature for comparing elements is in the realm of 
the possible.  That said, the other respondents made a reasonable case the 
different people would want to do it differently.  Despite your insistence that 
only your way makes sense, we do have to consider other users as well.  The 
other respondents provided you with other ways to meet your needs. Their 
disinclination to not add this feature is backed-up by years of experience with 
this module and with lxml.

Communication note: Please do not go down of the path of making yourself the 
arbiter of what is Pythonic or standard.  The other core devs in this 
conversation are highly experienced.  Insulting them or the Fredrik Lundh's 
existing API won't help matters.

We should add a clear note to the docs:  "Comparing the string serialized XML 
should not be used to establish semantic equality.  The preferred ways are to 
use C14N canonicalization or to write a tree walker where the notion of 
equivalence can be customized to include/exclude attribute order, to 
include/exclude comments or processing instructions, to include/exclude 
whitespace at non-leaf nodes".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marco Sulla]

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, the two dictionaries will be always equals, even if their id are 
not. 

I think that no one could say to remove this dictionary feature and simply 
check the ids, leaving the deep comparison to the user, without raising a 
rebellion :)

2. the fact that SubElement seems a constructor is not an implementation 
detail. It's misleading and confusing, since a programmer expects that it will 
return an object of type SubElement, while there's no SubElement class. This is 
peculiar. I can be wrong, but I never encountered such a bizarre naming in the 
standard library. IMHO SubElement should be deprecated and it should call 
`subElement()`, a simply copy of the old SubElement

3. I'm not suggesting to remove fromstringlist and tostringlist, but that they 
could be deprecated and simply call fromstring and tostring, that should use 
duck typing for doing what fromstringlist and tostringlist did.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Behnel]

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/blob/master/src/lxml/doctestcompare.py

https://docs.python.org/3.8/library/xml.etree.elementtree.html#xml.etree.ElementTree.canonicalize

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Behnel]

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 
execute.)

Regarding your other questions (and note that this is a bug tracker, so 
discussing unrelated questions in a ticket is inappropriate – use the Python 
mailing list instead if you want):

"SubElement" suggests a constructor, yes. It kind-of makes sense, given what it 
does, and resembles "Element", which is the constructor for a (non-sub) 
Element. It might seem funny, sure, but on the other hand, why should users be 
bothered with the implementation detail that it is a function? :-)

"fromstringlist()" matches "tostringlist()", API-wise. Both are probably not 
very widely used, but I don't see much value in removing them. It always breaks 
someone's code out there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 principal use case?

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +eli.bendersky, scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marco Sulla]

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 3.8 this could be not true anymore, since the order of 
insertion of attributes will be preserved. So if I simply wrote a tag with two 
identical attributes, but with different order, the trick will not work anymore.

Is it so much complicated to implement an __eq__ for `Element` that traverse 
its tree?

PS: some random remarks about xml.etree.ElementTree module:

1. why `fromstring` and `fromstringlist` separated functions? `fromstring` 
could use duck typing for the main argument, and `fromstringlist` deprecated.

2. `SubElement`: why the initial is a capital letter? It seems the constructor 
of a different class, while it's a factory function. I'll change it to 
`subElement` and deprecate `SubElement`

--
components: Library (Lib)
messages: 349230
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element.__eq__ does compare only objects identity
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com