#21198 closed Bug (fixed)
@python_2_unicode_compatible, abstract models, working on 1.4 but causing infinite loop on 1.5.
Reported by: | James Pic | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Utilities | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
On Django 1.4.2, I can call unicode(my_city) without any problem. my_city being an instance of City defined here: https://github.com/yourlabs/django-cities-light/blob/master/cities_light/models.py
As you can see:
- City inherits from Base abstract model,
- City is decorated by @python_2_unicode_compatible,
- Base is also decorated by @python_2_unicode_compatible,
- Base defines str
- City does not define str
When these conditions are met then Django 1.5 gets stuck in an infinite loop. The solution is to remove @python_2_unicode_compatible decorator from City.
Traceback: https://travis-ci.org/yourlabs/django-autocomplete-light/jobs/11953680
I don't know if this a lack of documentation or a bug.
Change History (7)
comment:1 by , 11 years ago
Component: | Uncategorized → Utilities |
---|---|
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Bug |
comment:2 by , 11 years ago
Thanks for the link, but I don't get why that would work on Django 1.4.2 and not on Django 1.5.4.
comment:3 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 11 years ago
Owner: | changed from | to
---|
comment:5 by , 11 years ago
#19362 was an earlier attempt at fixing this problem. The approach suggested here is more robust.
comment:6 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
The documentation makes it clear that
@python_2_unicode_compatible
is only intended for classes that have a__str__
method.https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.encoding.python_2_unicode_compatible
Django's historical behavior of building
__str__
from__unicode__
and backwards-compatibility concerns make@python_2_unicode_compatible
prone to infinite recursion.This is extremely hard to debug. It's impossible to print the object since
unicode
,str
andrepr
all go into infinite recursion. I'd like to raise a better exception instead.