Delete many redundant method redefinitions

[AlexWaygood]

All classes implicitly inherit from object in Python 3, so it's almost never necessary to explicitly define __str__ or __repr__ in the stubs (there are a few exceptions, if it's e.g. marked as an abstract method in a base class).

I haven't touched any of the files in the stubs directory in this PR, as some of those need compatibility with Python 2; this PR only touches the standard-library stubs.

[AlexWaygood]

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.

[JelleZijlstra]

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.

[JelleZijlstra]

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

[AlexWaygood]

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?

[JelleZijlstra]

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.

[AlexWaygood]

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 :)

[JelleZijlstra]

Not 100% sure about this since I could imagine a type checker checking whether an object can be pickled safely and checking __reduce__ overrides.

[AlexWaygood]

You've changed your tune ;)

[JelleZijlstra]

I guess I just default to not making changes when we don't have a clear reason for change :)

[AlexWaygood]

A sound policy.

[github-actions]

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

[AlexWaygood]

Thanks!