--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
Perhaps to have it a tiny little bit more useful, have it default to "MyModel object (object_pk)" ?
--
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+unsubscribe@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/c7254a96-7ee3-4262-a90b-83dcfe8fa3d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Makes sense to me. Maybe still keep the "Transaction object" part, and use None if no pk.
On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg <kapilg...@gmail.com> wrote:
Ticket 27953 is regarding this proposal and the suggestion is about adding "pk" in Model string representation if it exists.--
On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:Hi All,Have you ever quickly set up a model, ran syncdb, and added a few sample objects in the admin to only see a bunch of "MyModel object"s in the changelist? I always forget to add a __unicode__()/__str__() method on my models.I ran "git grep -1 __unicode__" on some of my django projects and noticed a lot of repeated code. In fact, it seems that in about a _third_ of all my cases, I'm just returning self.name, or returning self.name would have been a good default. I looked at a few 3rd party apps for comparison and found similar results, though not for every app.IMHO, returning self.name (if the field or property exists) is a sensible default for __unicode__. We can still return "MyModel object" if there's no "name" attribute. You'll still end up adding your own __unicode__ method much of the time, just like you always have.Yes, it's "magic", but we can document it.Yes, it's a little more confusing, but we don't have to explain it during the tutorial.Yes, it's backwards incompatible, but only in rare cases should it be a problem.Yes, it could look like any Model without a "name" field is "wrong", but it's not.Yes, "title" is also very popular, but name is better. :)It has the effect of being a little more friendly in many cases, and can result in more DRY code.What do your __unicode__/__str__ methods look like? Is this a bad idea?Thanks,Collin
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@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/1a84fb1c-522f-4bc4-b214-0831a63f13ae%40googlegroups.com.
diff --git a/django/db/models/base.py b/django/db/models/base.pyindex 3c1cb9a..f58e12b 100644--- a/django/db/models/base.py+++ b/django/db/models/base.py@@ -504,7 +504,7 @@ class Model(metaclass=ModelBase): return '<%s: %s>' % (self.__class__.__name__, u) def __str__(self):- return '%s object' % self.__class__.__name__+ return '%s object pk=%s' % (self.__class__.__name__, self._get_pk_val()) def __eq__(self, other): if not isinstance(other, Model):
maybe you should change it to self.cls??
def __init__(self, *args, **kwargs):
# Alias some things as locals to avoid repeat global lookups
cls = self.__class__
The opened ticket is about Model.__str__ method. Should i open a new ticket for this change ?
As i see in code, self.__class__ is used in a lot of places but will it effect optimization if we change lookups from self.__class__ to self.cls
Because the methods where class is being used frequently, already store it in local variable and then make references to local variable.
So should it really be changed ?
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/7Jqzwg5nt-c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/a776fdc4-4172-45ca-9a00-06016b24413a%40googlegroups.com.
To unsubscribe from this group and all its topics, send an email to django-developers+unsubscribe@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/a776fdc4-4172-45ca-9a00-06016b24413a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@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/CABAYvYp0Xn68hLN0Ne%3DGxWGhTFpMMFPYTJDR6cCStpGwRWCcKA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/eb14b116-cdc0-44bd-9f83-86edb5cc7525%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@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/a37f50c0-c58f-45ec-aa3c-dcc117fcece1%40googlegroups.com.
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).
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?