Питон, юникод и конвеер

http://stackoverflow.com/questions/492483/setting-the-correct-encoding-when-p...

Некрофилы должны страдать, такие дела, да.

верссиях 2.6 и 2.7
Fri Apr 24 2015

Вся суть в версии питона, скорее всего.

Как будто кто-то использует другие версии Python. И то 2.6 только в старом RedHad (и CentOS).

Все нормальные люди перешли уже на 3. Только фрики на 2.

Некрофилы должны страдать, такие дела, да.

Внезапно на моем Debian testing

$ python --version
2.7.8
$ cat /etc/debian_version
8.0

Внезапно на моем Debian testing

а apt-get install — там работает?

система зависимостей — работает?

Вся суть в версии питона, скорее всего.

вся суть в том что команда print так работает . :-)

print делает encode в *заведомо-известную* кодировку stdout (sys.stdout.encoding)

но так как в случае pipe — Пайсон не знает какая кодировка , то в этом случае print делает encode с использование *кодировки-поумолчанию* :-D для ситуаций с неизвестной кодировкой..

вот в этом весь и прикол.. тут (далее) раскрывается нюанс :-) :

* устаревший Python-2.X — считает что в случае неизвестной кодировки мы должны всегда использованить ASCII (независимо от того какая у нас локаль в системе..)

* а обычный Python-3.X — считает что в случае неизвестной кодировки мы должны использовать UTF-8 (независимо от того какая у нас локаль в системе.. даже если Eddy_Em разбанят :-) )

# вывод: поведение Python-2.X как обычно черезжопное .. и весь расчёт ведётся на то что пользователь будет вручную делать decode\encode не полагаясь на автоматику (и сверяться с локалью, если нужно). а поведение Python-3.X работает вполне удовлетворительно (так как если мы не знаем какая кодировка то UTF-8 в 99.99%-случаев окажется правдой :))

Скорее те, кто считает питон юзабельным языком.

Скорее те, кто считает питон юзабельным языком.

Вот только не надо опять начинать питоно-срачь, уже всё обсудили. Питон более чем юзабельный язык, в определенных областях удобнее многих.

но так как в случае pipe — Пайсон не знает какая кодировка , то в этом случае print делает encode с использование *кодировки-поумолчанию* :-D для ситуаций с неизвестной кодировкой..

и здесь я немного уточню..

например вы можете возрозить "но как же не знает?! почему Пайсон не может просто взять кодировку из информации Локале?"

ответ:

потому что Пайсон же понятия не имеет что этот "... | cat ..." выдаст информацию на экран! (ды и вообще — Пайсон и даже не знает что он вообще подключён к "cat" !)

Пайсон просто передаёт байты по PIPE без понятия о том кто это случает на другой стороне :-) ..

следовательно говорить об *автоматическом* использовании кодировки из локали — тут совершенно неуместно!

Объясните нубасу, зачем u"строка"?

$ python2 -c 's="ЛОР"
> print "Ололо привет {0}".format(s)' | cat
Ололо привет ЛОР

$ cat testlor 
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
s="ЛОР"
print "Ололо привет {0}".format(s)

$ ./testlor | cat
Ололо привет ЛОР

apr-get работает как часы, зависимости иногда подглючивают, но редко. последний libreoffice не очень работает с xmonad, но это проблема маргинальных оконных менеджеров: их никто не хочет поддерживать.

Возвращаясь к вопросу и для тех кто прийдет с поисковиков

import sys
import codecs
sys.stdout = codecs.getwriter('utf8')(sys.stdout)

Если ты получаешь свое s из файла, то по питон-теории ты должен его преобразовать в кодировку на которой написан твой скрипт. Про методы encode и decode у строк слышал же? Чтобы не заграмождать код, можно сказать принудительно, что вот строка s=u" в юникоде. У тебя нет юникода вот по этому и работает.

Про методы слышал. Если у меня файл в UTF-8 и скрипт в этой кодировке я могу ничего не (де)кодировать?

вообще хорошего *универсального* решения тут не думаю что можно придумать :)).

так как — вдруг stdout должен быть в другой кодеровке (не UTF-8) ? и должны ли мы хардкодно указывать UTF-8 или же должны ли мы взять значение из локали? это зависит от задачи..

но в целом — как костыль — это норм.

и можно этот костыль даже слегка улучшить:

import sys
import codecs
if not getattr(sys.stdout, 'encoding', None):
    sys.stdout = codecs.getwriter('utf8')(sys.stdout)

ну или сделать примерно-где-то-вот-так

import sys

def safe_print(*args, **kwargs):
    sep=kwargs.get('sep', u' ')
    end=kwargs.get('end', u'\n')
    file=kwargs.get('file', sys.stdout)
    
    def safe_conv(value):
        encoding = getattr(file, 'encoding', None) or 'utf-8'
        
        if isinstance(value, bytes):
            safe_value = value
        elif isinstance(value, unicode):
            safe_value = value.encode(encoding, 'replace')
        else:
            safe_value = unicode(value).encode(encoding, 'replace')
        
        return safe_value
    
    print_str = safe_conv(sep).join(safe_conv(v) for v in args) + safe_conv(end)
    
    file.write(print_str)
    file.flush()

Зависит от версии, но в общем ответ нет. Да и с какой радости? О чем и тред

и вся головная боль от этого Python-2.X — что нужно делать НЕ только "safe_print" [ см.. Питон, юникод и конвеер (комментарий) ]...

...но и вообще чуть ли не для каждой стандартной функции делать подобные врапперы, которые бы исправляли бы встроенное поведение на более адекватное :-)

так что «батарейки в комплекте» — слегка своеобразные :-)

Мне вообще интересно, какой сумрачный гений додумался до того, что кодировки при выводе на stdout и в файл/pipe должны различаться? В этм плане убогость второй и третьей веток абсолютно одинакова.

Для кого, черт возьми, LC_CTYPE задается?!

Мне вообще интересно, какой сумрачный гений додумался до того, что кодировки при выводе на stdout и в файл/pipe должны различаться? В этм плане убогость второй и третьей веток абсолютно одинакова.

Для кого, черт возьми, LC_CTYPE задается?!

вот поэтому я дополнительно и объяснил(*) :-)

с какого перепуга мы (то есть — Пайсон) должны пихать в PIPE именно то что красиво читается на дисплее пользователя (LC_CTYPE) ?

а вдруг PIPE предназначен НЕ для спросмотра его на дисплее? :-)

думаю вполне логично представлять PIPE как некий кросплатформеный канал (в отличии от того что печатается на мониторе) , ведь данные передаваемые по PIPE теоретически могут попасть и на другие компьютеры и на другие операционные системы..

с какого перепуга мы (то есть — Пайсон) должны пихать в PIPE именно то что красиво читается на дисплее пользователя (LC_CTYPE) ?

Как тебе такая аналогия: я пишу

printf("%d\n", 256);

Потому как CTYPE, в частности, влияет на то, как будут воспринимать ввод некоторые приложения. Он един для системы. Попытка в третьем питоне пропихнуть свой юникод во все щели тоже ни к чему хорошему не приводит.

Да и вообще, в 95% задач лучше, если язык считает строки «бинарными массивами переменной длины». Но из-за оставшихся 5%, когда нужнен юникодный collate и casefolding, страдают все.

ведь данные передаваемые по PIPE теоретически могут попасть и на другие компьютеры и на другие операционные системы

Это, кстати, аргумент в пользу «считать все строки потоком бинарных данных» и никоим образом не лезть в их начинку.

Считать строки бинарными данными можно только если ты их тупо, например, пересылаешь из одного места в другое, что происходит весьма редко.

Считать строки бинарными данными можно только если ты их тупо, например, пересылаешь из одного места в другое, что происходит весьма редко.

А также в подавляющих случаях фильтрации. Я, например, не припомню, чтобы мне когда-то был нужен регистронезависимый grep не по латинице.

Вообще «поддержка юникода на уровне языка программирования» очень сильно переоценена. Гораздо проще иметь библиотеку для collation, casefolding и разбиения на символы, чем на каждом шагу сталкиваться с тем, что произвольный набор байт в строку так легко не положить/не распечатать.

Это, кстати, аргумент в пользу «считать все строки потоком бинарных данных» и никоим образом не лезть в их начинку.

вот наверно поэтому в Python-3.X придумали два разны объекта:

«sys.stdout» — для вывода на дисплей..

и

«sys.stdout.buffer» — для всяких там PIPE и прочиго бинарного..

ну а уж когда мы (программисты) вместо «sys.stdout.buffer» используем «sys.stdout» [ а функция «print» как раз подразумевает «sys.stdout» ] — вот в этом случае мы (программисты) сами виноваты.

по сути Python3 только слегка разряжает обстановку в случае такой программистской ошибки (например программист писал программу для вывода на дисплей, а пользователь программы рашил заиспользовать запись потока в бинарный файл и передать результат через интернет)

Попытка в третьем питоне пропихнуть свой юникод во все щели тоже ни к чему хорошему не приводит.

по хорошему самым правильный способом — было бы просто СРАЗУ вывод ОШИБКИ если программист пытается в PIPE пропихнуть текстовый текст :-)

но вот решили в Python3 пощадить программистов и пропихнуть UTF-8 :-) .. не совсем идеологически правильно (быть может?!) но зато подходит под большенство use case и одновременно не создаюёт путанницу кодировок :-)

$ echo привет | tr п ы
ырѸѲѵт

Как только проводишь любое действие с отдельными символами (поиск подстроки, замена итд), в случае с utf-8, коллекцию байтов нужно декодить в строку (коллекцию символов).

Питон 3 utf-8 никоим образом не пропихивает (разве что теперь исходник по-дефолту считается текстом в utf-8). Он просто перестал неявно енкодить строки в байты и декодить байты в строки.

Питон 3 utf-8 никоим образом не пропихивает (разве что теперь исходник по-дефолту считается текстом в utf-8). Он просто перестал неявно енкодить строки в байты и декодить байты в строки.

вот тебе пример:

read_fd = open('in.txt', mode='rt') # открыть файл -- на чтение в режиме текста (используется кодировка в зависимости от Локали)
write_fd = open('out.txt', mode='wb')  # открыть файл -- на запись в режиме бинарника

text = read_fd.read()
binary = text.encode() # ВОТ ТУТ -- что происходит? какая кодировка?

write_fd.write(binary)

суть этого примера в том что Пайсон третьей версии — использует UTF-8 во всех тех моментах когда у Пайсона нет инфы о том какую кодировку использовать.

и это касается как видишь не только вопроса о кодировке программного кода :-)

sys.getdefaultencoding()

UTF-8 сделали дефолтной кодировкой, да. Но неявное преобразование между байтами и строками убрали.

Питон2: пишешь тупой код который работает, но потом внезапно взрывается на неASCII-вводе, и приходится выискивать все те места, где были неявные преобразования между string и unicode.

Питон3: теперь программисту нужно держать в голове отдельные концепты строк и байтов (даже если ему нужно лишь ASCII, где эти концепты совпадают), но UTF-8 сделали кодировкой по умолчанию.

Мне вообще интересно, какой сумрачный гений додумался до того, что кодировки при выводе на stdout и в файл/pipe должны различаться?

разработчики windows
для логгера например:

if sys.stdout.isatty():
	console_handler = logging.StreamHandler()
	console_handler.setLevel(logging.DEBUG)
	if sys.platform.startswith('win'):
		reload(sys)
		sys.setdefaultencoding('cp1251')
		sys.stdout = codecs.getwriter('cp866')(sys.stdout,'replace')
		windows_format = logging.Formatter(u'%(levelname)-8s [%(asctime)s]  %(message)s'.encode('cp1251'))