[Django] #22090: ModelAdmin list_filter field member values are serialized using __str__ and not __repr__
Django
not __repr__
--------------------------------------+--------------------------------
Reporter: sam@… | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: contrib.admin | Version: 1.6
Severity: Normal | Keywords: admin, list_filter
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------------------
When generating the filter URL query parameters corresponding to model
members with choice fields and specified in `list_filter` of ModelAdmin,
Django uses the __str__ method of each of the choices to generate the URL
query representation of each.
The Django docs specifically note the __str__ as being one which returns
an informal human readable representation:
https://docs.djangoproject.com/en/1.6/ref/models/instances/#str
Django should not be assuming that the __str__ value is unambiguous or
machine readable. The python standard noted at
http://docs.python.org/2/reference/datamodel.html regarding __repr__() is
that __repr__ should be the function used for outputting a machine
representation of the object:
"If at all possible, this should look like a valid Python expression that
could be used to recreate an object with the same value (given an
appropriate environment)."
The above described inconvenience means that I have to make the __str__
method in the values that I assign to my model members machine readable,
which is goes against both Django and Python recommendations and makes my
code messier.
--
Ticket URL: <https://code.djangoproject.com/ticket/22090>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution: needsinfo
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: new => closed
* needs_docs: => 0
* resolution: => needsinfo
* needs_tests: => 0
* needs_better_patch: => 0
Comment:
I'm not sure to understand your message.
Since you're referring to the `__str__` method of models, maybe you're
thinking of foreign keys, but in that case Django uses
`xxx__id__exact=yyy`, so there's no `__str__` or `__repr__` involved.
[https://docs.djangoproject.com/en/dev/ref/models/fields/#choices choices]
are an iterable of 2-uples where:
- the first item is an arbitrary object corresponding to the underlying
database field
- the second item a a string describing that object
Both should be unique to avoid ambiguity. Since the second item is
guaranteed to be a string, it's natural to use it in the URL. But once
again there's no `__str__` or `__repr__` involved.
Can you provide a sample models.py and admin.py that exhibits the problem
you're reporting?
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:1>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution: needsinfo
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
list_filter is using the __str__ value returned by the first member of the
choice tuple (value_object, human_readable_string). i.e. The __str__
representation of the value of the choice. I am arguing that list_filter
should use the __repr__ of value_object instead, since it is being used as
a serialized representation.
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:2>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution: needsinfo
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sam@…):
The above comment was me, forgot to put my email in
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:3>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: closed => new
* resolution: needsinfo =>
Comment:
I'm not sure I understand. Looking at a site of mine, list_filter is using
the *second* member of the choice tuple.
Bumping back to unreviewed.
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:4>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sam@…):
I haven't found the code responsible, but changing the return value of
__str__ to the machine readable representation changed the URL parameter
value used when list filtering to the machine readable representation
also. I deduce from this that the __str__ of the choice value is used as
the query parameter.
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:5>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I still don't understand what you're talking about. The second member must
be a string, not an arbitrary object.
Can you post the definition of your choices?
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:6>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sam@…):
Say that {{{(value, 'human readable choice string')}}} is one of the
choice tuples for some field, and {{{value}}} is an instance of my own
data-type python class which has an associated {{{models.Field}}} subclass
to which values of this type can be assigned. Then Django is using
{{{value.__str__()}}} as the URL parameter serialization when the web
browser in the admin site filters by that choice.
I am arguing that {{{__str__()}}} is not the right function to call to get
a serialisation, because {{{__str__()}}} is said by the official Python
documentation to be the 'informal' (human readable) representation,
whereas {{{__repr__()}}} is a formal representation which, as long as it
makes sense, should be suitable for formal representation (such as
serialization) if possible. Django's current behaviour means that my
custom field class must be able to parse whatever is returned by
{{{value.__str__()}}} in order to correctly filter the admin page.
My complaint is perhaps more of a stylistic point but I think that
consistency with Python best-practice is worthwhile. Otherwise, my
{{{value.__str__()}}} function can not possibly be made to give an
'informal' representation without breaking the Django admin.
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:7>
Django
not __repr__
Reporter: sam@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: 1.6
Component: contrib.admin | Resolution: needsinfo
Severity: Normal | Triage Stage:
Keywords: admin, list_filter | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by bmispelon):
* status: new => closed
* resolution: => needsinfo
Comment:
I've also tried and failed to reproduce the problem described in this
ticket.
Can you provide some code example that demonstrate your issue?
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/22090#comment:8>