Repository navigation
Refactor "repr" objects #3399
Description
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?
xref: #3343
Activity
RonnyPfannschmidt commentedon Apr 13, 2018
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 commentedon Apr 15, 2018
Maybe we want to pass around objects that implement an interface:
serialize,deserialize, andtoterminal. I would avoid calling these objects anything with repr in the name, it's confusing that the "repr" of something isn't just a stringRonnyPfannschmidt commentedon Apr 15, 2018
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 commentedon Apr 21, 2018
@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:
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 commentedon Apr 21, 2018
as increment i propose adding an actual exception attribute to the reprs which is optional and planned for removal in the overhaul
RonnyPfannschmidt commentedon Sep 18, 2023
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
RonnyPfannschmidt commentedon Sep 21, 2026
Written by Claude Fable 5.1 via Claude Code for the pytest maintainers; I prompted it, it did the work, I read it.
Superseded by #15072, which carries the strategy this issue asked for: capture, a plain-data model, and rich-based renderers, with the increments to get there.