Thanks Christophe Mike
On 13/04/2017 2:31 AM, Christophe Pettus wrote:
On Apr 12, 2017, at 02:26, Antonis Christofides <anto...@djangodeployment.com> 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 x...@thebuild.com
-- 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/462c4311-1233-5443-2d18-c24ec24cde68%40dewhirst.com.au. For more options, visit https://groups.google.com/d/optout.
