Hi Collin, On Tuesday, December 12, 2017 at 3:48:38 PM UTC+1, Collin Anderson wrote:
> Yes, having a good __str__ is important, and thats why i think defaulting > it to the pk is good, because it's better than nothing. Yes, you'll still > want to override __str__ with something better (that likely doesn't include > the PK). > I slightly disagree on this specific point, but I don't think my squabble is worth wasting anyone's time :) So if you're overriding __str__ anyway, why not also override __repr__ to > include the PK? > > Or what are you actually proposing, something like this? > https://github.com/django/django/compare/master...collinanderson:patch-12 > Yeah, I just want something like your PR. I want to override __str__ most of the time, so having it include the PK doesn't do much for me- neither good or bad, but having the default __repr__ include the PK saves me from overriding it most of the time. I could nitpick on my ideal implementation of both methods, but I think it comes down to personal taste so I just wanted to propose having PK in the default __repr__ implementation as I think that will benefit people. The rest doesn't matter that much to me. Thank you, Álex -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b0618a9b-fc58-4057-a06f-16bd884ebdc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
