Extending attrs-generated `__eq__`

[AdrianSosic]

Hi, I fear that there is probably a super obvious answer to this question, but I somehow cannot wrap my head around it: is there any way how I can "extend" the attrs-generated __eq__ method, similar to how it's possible for __init__ by calling __attrs_init__? 🤔

Here just a dummy example to illustrate the situation. Right now, the only way I can get it work is by writing the boilerplate myself.

from attrs import define

magic_object = object()
"""Is equal to all objects."""


@define
class X:
    here: int
    are: float
    many: str
    fields: bool

    def __eq__(self, other):
        if other is magic_object:
            return True
        
        # Ideally, I want to call something like:
        # return __attrs_eq__(other)

        # Instead, I have this boilerplate code!
        return (
            super().__eq__(other)
            and isinstance(other, X)
            and self.here == other.here
            and self.are == other.are
            and self.many == other.many
            and self.fields == other.fields
        )


assert X(0, 0.0, "a", True) == X(0, 0.0, "a", True)
assert X(0, 0.0, "a", True) != X(0, 0.0, "a", False)
assert X(0, 0.0, "a", True) == magic_object

[hynek]

No there's not, and I don't think we'll ever add that – it's a bit… too specific. :)

I think you should be able to implement this using the magic object? dirty-equals seems to have some how achieved that?

[AdrianSosic]

Ah, I see! Thanks for taking the time to answer 👌🏼

Regarding specificity: well, I think it depends very much on how we look at the issue. For clarification: Please be aware that my "magic object" here was just for demonstration purposes – it doesn't even exist in my real-world use case!

What I mean instead is – as far as I believe – at the very heart of the attrs goal of reducing boilerplate and completely generic: take any existing attrs class and enable to inject custom logic into __eq__. Tbh, I don't see much difference compared to the __attrs_init__ workflow: attrs takes over the boilerplate, the user takes over the customization.

To emphasize why such a solution can be really useful: consider the case where my fields above even have custom eq overrides themselves. Without an __attrs_eq__ that simply writes the boilerplate part, I'd need to write the complete part myself – which comes with the very same downsides that motivate attrs usage in the first place (e.g. repetition, error-proneness because one can easily forget stuff, in particular when then classes are evolving, etc...)

Does this resonate with you? 🙃

[AdrianSosic]

One could also argue that an __attrs_eq__ would simply be the equivalent / generalization of field(eq=...) but on the class level instead of the attribute level. So just like __attrs_init__ is for handling cases that cannot be solved on a per-attribute basis, __attrs_eq__ would allow to handle equality checks that cannot be resolved on a per-attribute basis.