Good idea Eric, it should work.

But it can make the code of pprint potentially less flexible. Currently it uses a mapping which maps __repr__ to corresponding pprint implementation. Only exception is for dicts, for historical reasons. It potentially can allow to make pprint more general and support arbitrary types by registering some handlers. Since there is no standard implementation of __repr__ for namedtuples and dataclasses we cannot use them as keys, and need to hardcode checks for namedtuple and dataclass (and any other generated classes).

It is a minor objection. Perhaps practicality should beat purity in this case.