> On Apr 12, 2017, at 02:26, Antonis Christofides > <[email protected]> wrote: > >> Does this mean I should globally replace "str(" with "|six.text_type(" in a >> 2/3 codebase?| > I don't think so; afaiu this must be done for the return value of __str__(), > not > everywhere.
The rules as I understand them are: 1. Define __str__(), not __unicode__() on classes. 2. Decorate your class with @python_2_unicode_compatible. 3. Always return six.text_type from your __str__() function. 4. When casting a class instance to text, use six.text_type(), and not str() (unicode() still works, but it's not Python 3). In Python 3, this is all a no-op: The __str__() method returns Python 3's string class, which is Unicode. In Python 2, the decorator uses your __str__() method for the class' __unicode__() method, and creates a new __str__() method that returns a Python 2 string (not unicode) object, UTF-8 encoded. Personally, I would prefer to use the Python 2 'unicode' type everywhere I can in Python 2, so casting everything to six.text_type (and use from __future__ import unicode_literals etc.) would do that. -- -- Christophe Pettus [email protected] -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8519F123-1AF9-47A1-A9DC-97C8046AE373%40thebuild.com. For more options, visit https://groups.google.com/d/optout.
