Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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 Aymeric Augustin, 10 years ago

Component: UncategorizedUtilities
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

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 and repr all go into infinite recursion. I'd like to raise a better exception instead.

comment:2 by James Pic, 10 years ago

Thanks for the link, also, it seems like the error is the same in both 1.4.2 and 1.5.4, sorry for the false alarm.

Anyway, it does kinds of look like the user should use @python_2_unicode_compatible on any model class that is "Python2-unicode-compatible", even by inheritance.

So maybe it would be cool to raise a specific exception if @python_2_unicode_compatible is applied on a class without an __str__ method indeed. That would avoid the need of checking the documentation for the user :D I myself had only checked the "porting" guide and not the API docs (obviously, my bad).

Last edited 10 years ago by James Pic (previous) (diff)

comment:3 by chmodas, 10 years ago

Owner: changed from nobody to chmodas
Status: newassigned

comment:4 by Aymeric Augustin, 10 years ago

Owner: changed from chmodas to Aymeric Augustin

comment:5 by Aymeric Augustin, 10 years ago

#19362 was an earlier attempt at fixing this problem. The approach suggested here is more robust.

comment:6 by Aymeric Augustin <aymeric.augustin@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In f0c7649b1692f8441eb9b9b923b2bed8e95f9185:

Fixed #21198 -- Prevented invalid use of @python_2_unicode_compatible.

Thanks jpic for the report and chmodas for working on a patch.

Reverts 2ea80b94. Refs #19362.

Conflicts:

tests/utils_tests/test_encoding.py

comment:7 by Aymeric Augustin <aymeric.augustin@…>, 10 years ago

In 589dc49e129f63801c54c15e408c944a345b3dfe:

Fixed #21198 -- Prevented invalid use of @python_2_unicode_compatible.

Thanks jpic for the report and chmodas for working on a patch.

Reverts 2ea80b94. Refs #19362.

Note: See TracTickets for help on using tickets.
Back to Top