Refactor "repr" objects

[nicoddemus]

Follow up of #3361 (comment).

@RonnyPfannschmidt could you write down the strategy you have in mind to refactor the repr objects and what is the problem with their design currently?

cc @brianmaissy @whimboo

xref: #3343

[RonnyPfannschmidt]

i do not have a strategy as of now

the design flaws are mostly based in mixing output styling mechanisms with the representation mechanism

in addition serialization capabilities are missing completely

[brianmaissy]

Maybe we want to pass around objects that implement an interface: serialize, deserialize, and toterminal. I would avoid calling these objects anything with repr in the name, it's confusing that the "repr" of something isn't just a string

[RonnyPfannschmidt]

deserialize cant work that way
serialize needs help in order to be deserializable
toterminal is a massive issue (as its contrary to supporting sane ux, or other outputs like junitxml, pytest-html or a pytest-"gui"

[nicoddemus]

@RonnyPfannschmidt it seems you want a complete overhaul of the "repr" objects (which I agree could use a better name). Problem is that we 1) don't even know what the "overhaul" is and 2) we don't have the man power to even discuss it right now (it seems to me).

The refactoring discussed here won't change what you see that's bad about the current design, but:

1. It will improve the current state of things: the internal design will be more formal and more well thought; in particular I don't see that it will introduce further complication, in fact it will simplify things.
2. It will solve a number of problems that we have today, specially the serialization of the traceback representation in xdist.

So I propose we aim to incremental improvement rather than stop everything on its tracks hoping for a perfect solution, which might never even happen. What do you think?

[RonnyPfannschmidt]

as increment i propose adding an actual exception attribute to the reprs which is optional and planned for removal in the overhaul

[RonnyPfannschmidt]

while reviewing what the std-lib currently has to offer,
i took note that the objects there can serve a s a nice example api with the caveat, that safe reprs are not used and formatting choices may slightly differ

however statement range finding and other details may really want to use python 3.11 features for co_positions