Python __str__ против __unicode__

Question

Есть ли соглашение по Python, когда вы должны реализовать __str__() против __unicode__(). Я видел, как классы переопределяют __unicode__() чаще, чем __str__(), но это не похоже на согласованность. Существуют ли конкретные правила, когда лучше реализовать одно против другого? Нужно ли / хорошая практика для реализации обоих?

Answer 1

__str__() - старый метод - он возвращает байты. __unicode__() - новый, предпочтительный метод - он возвращает символы. Имена немного сбивают с толку, но в 2.x мы застряли с ними из соображений совместимости. Как правило, вы должны поместить все ваши строки форматирования в __unicode__() и создать заглушку __str__() метод:

def __str__(self):
    return unicode(self).encode('utf-8')

В 3.0 str содержит символы, поэтому те же методы называются __bytes__() и __str__(). Они ведут себя как ожидалось.

Answer 2

Если бы я не особо заботился о микрооптимизирующей строковой классификации для данного класса, я бы всегда реализовывал только __unicode__, так как он более общий. Когда я забочусь о таких незначительных проблемах производительности (что является исключением, а не правилом), имея только __str__ (когда я могу доказать, что в строковом выводе никогда не будет символов, не являющихся ASCII) или оба (когда возможны оба варианта) ), может помочь.

Это, на мой взгляд, твердые принципы, но на практике это очень распространено в KNOW, что не будет ничего, кроме символов ASCII, без усилий доказать это (например, в строковой форме только цифры, пунктуация и, возможно, короткое имя ASCII; ) в этом случае довольно типично перейти непосредственно к подходу «просто __str__» (но если бы команда программистов, с которой я работал, предложила местное руководство, чтобы избежать этого, я был бы +1 в предложении, так как это легко ошибиться в этих вопросах И «преждевременная оптимизация - корень зла в программировании»; -).

Answer 3

Поскольку мир становится все меньше, есть вероятность, что любая строка, с которой вы столкнетесь, в конечном итоге будет содержать Unicode. Таким образом, для любых новых приложений вы должны по крайней мере предоставить __unicode__(). Если вы тоже переопределите __str__(), это просто вопрос вкуса.

Answer 4

Если вы работаете в python2 и python3 в Django, я рекомендую декоратор python_2_unicode_compatible:

Django предоставляет простой способ определения str () и unicode (), которые работают на Python 2 и 3: вы должны определить str ( ) метод возврата текста и применения декоратора python_2_unicode_compatible ().

Как отмечалось в предыдущих комментариях к другому ответу, некоторые версии future.utils также поддерживают этот декоратор. В моей системе мне нужно было установить более новый модуль future для python2 и установить future для python3. После этого, вот функциональный пример:

#! /usr/bin/env python

from future.utils import python_2_unicode_compatible
from sys import version_info

@python_2_unicode_compatible
class SomeClass():
    def __str__(self):
        return "Called __str__"


if __name__ == "__main__":
    some_inst = SomeClass()
    print(some_inst)
    if (version_info > (3,0)):
        print("Python 3 does not support unicode()")
    else:
        print(unicode(some_inst))

Вот пример выходных данных (где venv2 / venv3 являются экземплярами virtualenv):

~/tmp$ ./venv3/bin/python3 demo_python_2_unicode_compatible.py 
Called __str__
Python 3 does not support unicode()

~/tmp$ ./venv2/bin/python2 demo_python_2_unicode_compatible.py 
Called __str__
Called __str__

Answer 5

Python 2: Реализовать только __str __ () и вернуть юникод.

Когда __unicode__() опущен и кто-то вызывает unicode(o) или u"%s"%o, Python вызывает o.__str__() и преобразует в Unicode, используя системную кодировку. (См. документация __unicode__().)

Обратное неверно. Если вы реализуете __unicode__(), но не __str__(), тогда, когда кто-то вызывает str(o) или "%s"%o, Python возвращает repr(o).

---

Обоснование

Зачем возвращать unicode из __str__()?
Если __str__() возвращает юникод, Python автоматически преобразует его в str, используя системную кодировку.

В чем выгода?
① Это освобождает вас от беспокойства о том, что такое системная кодировка (т. Е. locale.getpreferredencoeding(…)). Мало того, что это грязно, лично, но я думаю, что система должна заботиться в любом случае. ② Если вы будете осторожны, ваш код может оказаться кросс-совместимым с Python 3, в котором __str__() возвращает юникод.

Разве не обманчиво возвращать юникод из функции с именем __str__()?
Немного. Тем не менее, вы, возможно, уже делаете это. Если у вас from __future__ import unicode_literals вверху файла, есть большая вероятность, что вы вернете юникод, даже не зная об этом.

А как насчет Python 3?
Python 3 не использует __unicode__(). Однако если вы реализуете __str__(), чтобы он возвращал юникод в Python 2 или Python 3, то эта часть вашего кода будет перекрестно совместимой.

Что если я хочу, чтобы unicode(o) существенно отличался от str()?
Реализуйте и __str__() (возможно, возвращающий str) и __unicode__(). Я предполагаю, что это было бы редко, но вы могли бы хотеть существенно различного вывода (например, ASCII-версии специальных символов, таких как ":)" для u"☺").

Я понимаю, что некоторые могут найти это противоречивым.

Answer 6

Стоит отметить тем, кто не знаком с функцией __unicode__, некоторые из поведений по умолчанию, окружающих ее обратно в Python 2.x, особенно когда они определены рядом с __str__.

class A :
    def __init__(self) :
        self.x = 123
        self.y = 23.3

    #def __str__(self) :
    #    return "STR      {}      {}".format( self.x , self.y)
    def __unicode__(self) :
        return u"UNICODE  {}      {}".format( self.x , self.y)

a1 = A()
a2 = A()

print( "__repr__ checks")
print( a1 )
print( a2 )

print( "\n__str__ vs __unicode__ checks")
print( str( a1 ))
print( unicode(a1))
print( "{}".format( a1 ))
print( u"{}".format( a1 ))

дает следующий вывод консоли ...

__repr__ checks
<__main__.A instance at 0x103f063f8>
<__main__.A instance at 0x103f06440>

__str__ vs __unicode__ checks
<__main__.A instance at 0x103f063f8>
UNICODE 123      23.3
<__main__.A instance at 0x103f063f8>
UNICODE 123      23.3

Теперь, когда я раскомментирую метод __str__

__repr__ checks
STR      123      23.3
STR      123      23.3

__str__ vs __unicode__ checks
STR      123      23.3
UNICODE  123      23.3
STR      123      23.3
UNICODE  123      23.3