Diff from mypy_primer, showing the effect of this PR on open source code:

zulip (https://github.com/zulip/zulip)
+ corporate/views/billing_page.py:115: error: Unrecognized format specification "%B"  [str-format]
+ corporate/views/billing_page.py:117: error: Unrecognized format specification "%B"  [str-format]

pandas (https://github.com/pandas-dev/pandas)
+ pandas/io/formats/format.py:2065: error: Non-overlapping equality check (left operand type: "Decimal", right operand type: "Literal[0]")  [comparison-overlap]

I assume Decimal.__eq__ and datetime.__format__ are special-cased by mypy in some way. I'll add them back.

I assume Decimal.eq and datetime.format are special-cased by mypy in some way. I'll add them back.

More likely it distinguishes between classes that override __eq__ or __format__ and ones that just use the signature from object. This makes sense because object.__format__ errors on any non-empty format string, but an override may accept more arguments.

So as a corollary, we should not remove any other __eq__/__format__/__ne__ methods.

More likely it distinguishes between classes that override eq or format and ones that just use the signature from object. This makes sense because object.format errors on any non-empty format string, but an override may accept more arguments.

Sure, that makes sense for __format__, but I still don't really get Decimal.__eq__. Should I put all of the __eq__ methods back?

I don't have time to look into the details right now (got a lot of things to catch up with), but I believe mypy's logic for unsafe == treats overridden __eq__ specially.

I don't have time to look into the details right now (got a lot of things to catch up with), but I believe mypy's logic for unsafe == treats overridden __eq__ specially.

I'm reverting it as we speak, dw! Was just curious, it's obvs not your job to figure it out for me :)

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

Thanks!