2013/5/19 Karen Tracey <kmtra...@gmail.com>: > I agree with Anssi, repr should stay as-is. I do a lot of shell/pdb work and
In interactive mode it's just as easy to call __unicode__ as it is to call __repr__. On the other hand __repr__ is used by automated tools such as crash reporters (raven). > I can't recall ever encountering a problem with "unsafe" repr. We had it explode a number of times when coupled with postgres. In that case instead of the original exception, all you get is: psycopg2.ProgrammingError: current transaction is aborted, commands ignored until end of transaction block > I think many > people would find it annoying if suddenly repr would tell you no more than > the pk of the object. I'd argue that the PK is actually more important than whatever __unicode__ returns. It's really annoying to find a stack trace that only contains product's title when you have tens of millions of products on production and title is not an indexed field. And by that time it's already too late to override __repr__. On the other hand it's fairly easy to extend __repr__ to display other information if you find it more useful than the PK. Backward compatibility should not be a concern here as no code should depend on whatever __repr__ chooses to return. -- Patryk Zawadzki I solve problems. -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
