On 18 touko, 19:04, Patryk Zawadzki <[email protected]> wrote: > As suggested by Marc Tamlyn I am posting this here for discussion: > > https://code.djangoproject.com/ticket/20448 > > tl;dr: > > Currently __repr__() calls __unicode__() which can be a very bad > thing. You really don't want things like an exception being raised or > debugger being used to cause additional side effects (like executing a > database query inside __unicode__).
There was very similar discussion recently (maybe in some ticket, I don't remember where) about QuerySet.__repr__(). IIRC the conclusion was that executing SELECT queries as part of __repr__() is OK. The reasoning had four points: 1. This is the way it has always been 2. Due to #1, changes in __repr__() will cascade to a lot of tutorials etc which use the current repr format. 3. SELECT queries should be safe (for QuerySet SELECT FOR UPDATE not so safe...) 4. __repr__() is more informative the current way So, changing the way Model.__repr__() works should consider those four points. To me it seems that points #1 - #3 apply directly, maybe also #4. I think we can keep things as is. I do see that the current way can be problematic in some cases, but at least for Model.__unicode__(), if you know it is unsafe, then write your own safe __repr__(). And if it is decided that this change is after all needed, then doing changes to both QuerySet.__repr__() and Model.__repr__() should be done in one go. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
