Safe repr for error pages

Django Internals
1

I suggest all error pages, messages, exceptions, etc that today use repr() be changed to use a “safe repr” function that is not overridable by the user. Something like:

def safe_repr(obj):
    if isinstance(obj, Model):
        return f'<{type(obj).__name__} pk={obj.pk}>'
    else:
        return f'<{type(obj).__name__}>'

This would fix the following issues:

The disadvantage is that some people will get less useful repr() if they’ve been careful to make good reprs. Unfortunately it’s quite easy to accidentally make a dangerous repr, due to the fact that Djangos default __repr__ calls __str__.

Edit:
To be really safe, this behavior could be opt-in, with a deprecation period for the non-enabled state.

2

This seems like the same issue are you’ve posted before… — even if it’s a variant, it’s related. It would be good to try and keep related topics all together, rather than creating small variant threads. Duplicates force people to go and find the old conversation, to remember what was said. They also risk the reasons given previously being forgotten/overlooked.

There have been other discussions in this space too. It would be worth trying to corral the considerations to see if we can resolve/improve the underlying issue.

3

Ah, sorry, I forgot about that one. Yea, this is an ongoing saga for sure.

In any case, this is a quite different idea, and one that is much more robust imo.

4

This is exactly what I’m trying to do here. The previous attempts have all run into roadblocks (changing default repr and improving DoesNotExist), or have introduced new issues (improved MultipleObjectsReturned). I think/hope this solution would handle all these cases.

5

TBH Seems like it’s the exact same point again… Debug output is definitely discussed.

Previous iterations have concluded the existing __repr__ is a feature, and folks should override if they need something else.

The history of this topic is very long — much more helpful would be a review of (all) that history and then possible routes forward.

6

The same area sure. This specific suggestion? I don’t believe so, but maybe I missed something.

That’s kinda the point of this specific suggestion: trying to solve a wide variety of issues that have a common underlying issue, going back over a decade.

This is exactly what my suggestion does.

7

What it does is to bypass the historical discussion. What’s needed is to show how points made in the past have been accounted for.

FWIW it doesn’t do that. Using a new function admittedly doesn’t change the QuerySet/Model repr implementation, but it does change the output — which was the precise thing folks were keen to maintain.

Equally (FWIW) this does keep coming up, so maybe there is a route forward, but we can’t just pretend that the history is not there, or has been adequately accommodated when it hasn’t.

I’m going to unsubscribe from this thread.

8

I reread all the text you linked to.

My summary:

  • The objection that the repr would sometimes change was quite a minor point, and no one seemed to have very strong feelings about this. I also, of course, already mentioned this at the very start of this discussion.
  • There were several quite bad side effects of the current system mentioned. None were even acknowledged. The issue with transactions for example is quite bad in itself. This is also solved by my suggestion.

I linked to several past discussions. I don’t understand why you keep insinuating things that are clearly not true. I didn’t link to 100% of all past discussion, that’s true, but I certainly did not “pretend that the history is not there”.