Sorry for not being clear enough.
The default back to object identity is exactly the issue here.
Here is the example that got me to make this function:
I have a class `dataset` which can be built as follows: `mydata1 =
dataset('path/to/dataset1')`
Then I can create a second dataset `mydata2 = dataset('path/to/dataset1')`
(no typo about `path/to/dataset1`, it is a 1).
Thus testing `mydata1==mydata2` will return false while they actually
contain the same information and data.
Regarding parent class comparison, I would assume that there is a good
reason to have made that class `MyStr` hence either some of its methods or
attributes will end up being different from `str`. So testing directly for
the class is only a faster way to find the difference. I don't really see
the problem with saying that objects of two different classes will always
be different (unless the object implements its own `__eq__` function in
which case the user can use the `==` operator). It's like comparing apples
to oranges. They're bound to be different.
Just in case that this is ambiguous too: I am not suggesting to change the
behaviour of the equality operator, just to provide the user with an extra
function for a more comprehensive (and slower) comparison operator/function.
I also found another workaround for my case (pass the constructor
parameters instead of the object) but I just thought it could be useful to
others.
Turns out maybe not :-)
Sorry for the disturbance then.
I didn't know about @dataclass, I'll look into that. Thanks for the pointer.
Best regards,
*Sébastien Eskenazi*
<http://goog_31297828>
<https://www.pixelz.com>
Pixelz
15th Floor, Detech Tower 2 Building, 107 Nguyen Phong Sac,
Hanoi, Vietnam
<https://www.linkedin.com/in/sebastieneskenazi/>
Beautiful Images Sell Products
Learn eCommerce Photography and Image Editing Tips on the Pixelz Blog
<http://www.pixelz.com/blog/>!
On Thu, 26 Sep 2019 at 09:58, Andrew Barnert <[email protected]> wrote:
> 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/V3MS6DQ4633G5AW6KBLZ3VD2XBZAWLGD/
Code of Conduct: http://python.org/psf/codeofconduct/
