On Sep 25, 2019, at 02:15, Sébastien Eskenaz <[email protected]> wrote: > > Hello, > > Several libraries have complex objects but no comparison operators for them > other than "is" which checks if we are comparing an object with itself.
Most of them also have == which does the same comparison, because you get that by default. Breaking that would be a backward compatibility nightmare. And the ones that don’t have deliberately disabled equality comparison, probably for some good reason, so it’s probably an even worse idea to break them. > It would be quite nice to be able to compare any two objects together. Sure, but there’s no rule that makes sense for every type. There is a large set of classes where “compare for equality by comparing all attributes for equality” makes perfect sense. And even a pretty large subset of that where “compare for order by comparing attributes lexicographically in their natural attribute order” makes sense too. But it’s definitely not all classes. For example, let’s say you have a DOM node class. Presumably you want == to be true of two nodes that head equal (sub)trees. But if the children are accessed by a method call, or by iterating, not by an attribute, your algorithm does the wrong thing. Or, if there’s a back link to the parent that is an attribute, again it does the wrong thing. Not to mention that, because Python is ridiculously dynamic, you can have classes where there’s not even a way to get a list of all attributes—think of a remote proxy or a bridge to another language. Also, even for some classes that _could_ be correctly compared this way, it still might not be a good idea. For example, comparing two HTTP responses by their content arguably does the right thing. But do you want r1 == r2 to potentially block for 20 seconds while it downloads two complete resources over the network? To compare both raw content and decoded text because there are properties for both even though they’re redundant? To raise an exception about a network error? I think “classes that you’d want to compare by lexicographically comparing attributes” overlaps pretty well with “classes that could have been defined with @dataclass”. Classes that actually _are_ defined with @dataclass already get comparison operators for free, but there are tons of classes that maybe would use @dataclass in an ideal world, but they predate it, or need to work with Python 3.5 or 2.7, or need a custom metaclass, or have some behavior that doesn’t play nice with some of the limitations of @dataclass, etc. So those are the ones you care about. If your algorithm would work for 90% of those classes (which means you don’t need to deal with every weird edge case—just declare that Infinite attribute cycles aren’t part of the 90% you handle), and you had an easy way to monkeypatch or wrap the handful of classes you actually need to compare on a given app, would that be good enough? Because I think you could write that pretty easily, and it might give you everything you’re looking for. _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YXSH2D7QFRGHSGNHDH5J5FXSC5PRTTW6/ Code of Conduct: http://python.org/psf/codeofconduct/
