Opened 22 months ago

Closed 22 months ago

Last modified 22 months ago

#21198 closed Bug (fixed)

@python_2_unicode_compatible, abstract models, working on 1.4 but causing infinite loop on 1.5.

Reported by: jpic Owned by: aaugustin
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 Changed 22 months ago by aaugustin

  • Component changed from Uncategorized to Utilities
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Bug

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 Changed 22 months ago by jpic

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 22 months ago by jpic (previous) (diff)

comment:3 Changed 22 months ago by chmodas

  • Owner changed from nobody to chmodas
  • Status changed from new to assigned

comment:4 Changed 22 months ago by aaugustin

  • Owner changed from chmodas to aaugustin

comment:5 Changed 22 months ago by aaugustin

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

comment:6 Changed 22 months ago by Aymeric Augustin <aymeric.augustin@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

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 Changed 22 months ago by Aymeric Augustin <aymeric.augustin@…>

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