LINUX.ORG.RU

[python] Gtk + Utf8 + Unicode <- живут в дружбе и мире благодаря грязному Хаку?

 


0

1

рассказываю всё попорядку:

Глава 1. введение::

из чтения документаций — заметил что в Gtk-фреймворке в принцепе в основном используются байтовые строки (а не Unicode-строки)

....однако Unicode`ные строки тоже хорошо работают... (все Gtk-функции их свободно «понимают» )

тоесть оба варианта работают и официально щитаются корректными:

my_text_entry_1.set_text(  b'байтовая строка'  )
my_text_entry_2.set_text(  u'юникодная строка'  )
Глава 2. слегка необычное удобство::

однако можно делать даже так (!):

# даже в случае не-ascii символов в GTK-строке -- свободно извлекается юникодный объект:
unistr = unicode(my_text_entry.get_text()) # хотя ОБЫЧНО -- в Python-2 (в отличии от Python-3) это делать нельзя, 
                                           # без явного указания кодировки. (например xxxx.decode('UTF-8') )
этот блок текста мне показался немного НЕОБЫЧНЫМ — ведь для преобразования между Байтовой-Строкой <=> Юникодной-строкой — обычно как-раз используется функция-конвертирования в которой в качестве аргумента фигурирует имя кодировки..

и праграммист должен ТОЧНО (на 100%) ЗНАТЬ — какая конкретно кодировка имеется ввиду.

например для кодирования НАЗВАНИЯ файлов используется одна кодировка, а для кодированиях СОДЕРЖАНИЯ файлов — другая кодировка . для кодирования символов ТЕРМИНАЛА используется третья кодировка .. вобщем — для каждой сущности в операционной системе — как правило существует своя кодировка... некоторые кодировки в различных операционных системах повторяются (например кодировка не-юникодного GUI в Windows совпадает с кодировкой содержимого текстовых файлов (но эта кодировка отличается от кодировки имён файлов и кодировки терминала) .. в других операционных системах схожести и различия могут быть другие...

...так-что каждый программист который пишет кросплатформенную программу должен везде (для каждой сущности) — использовать специальную кодировку название которой — извлекается через ту-или-иную _соответствующщую_ спец-функцию (а не вбивается через исходный код) .

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

но если GTK не требует указывать кодировку для своих Виджетов при оперировании Юникодными объектами — то значит с программиста сподает очередная головная боль .. программисту не придётся задумываться над вопросом: «а верно ли я понимаю какую я должен использовать кодировку для GTK-виджетов»

Глава 3. необычность выходит за рамки Gtk::

оказывается что в Gtk программах рабтает даже ЭТО(!!!):

unistr = u'внутри юникодной строки -- %s . вот так-то!' % b'байтовая строка'
btstr = b'внутри байтовой строки -- %s . вот так-то!' % u'юникодная строка'
# привет миру Python-3 -- где такое возможно "из-коробки" :-) , для любых программ
так-так.... попахивает грязным хаком, который исправляет поведение целого Пайтона при использовании GTK

Глава 4. а вот тут — хак таки-пойман с поличным::

простая Пайтон-программа из четырйх строчек:

import sys
print sys.getdefaultencoding() # печатает: ascii
import gtk
print sys.getdefaultencoding() # печатает: utf-8

вот оказывается почему (изза этого хака) — так свободно PyGTK оперирует с Юникодными-строками... тоест ьпо сути поддержки юникодных строк в PyGTK — нет :-( :-(

[и вместо того чтобы переписать все PyGTK-функции из Байтовых-строк на Юникодные-строки, разработчики решили просто сделать — ЭТО]

Глава 5. эпилог::

что думаете про всё это? :-)

***

и вот ещё вопрос — как они реализовали этот «хак» ? ведь функция sys.setdefaultencoding(...) [ http://j.mp/92lnL6 ] — не работает %) %)

былобы полезно заюзать этот хак и не в GTK-программах :-)

(GTK не изменяет указатель на функцию sys.getdefaultencoding .. — это проверял )

Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> enc = sys.getdefaultencoding
>>> enc()
'ascii'
>>> import gtk
>>> enc()
'utf-8'
>>>

Ответ на: комментарий от hibou

> Не все прочитал,

тогда начни с конца :-)

Учи лучше Си.


ну вообще Python и C — это не взаимоисключающие вещщи :-) .. модули можно и на C написать :-)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

Я про то, что gchar пофиг в какой кодировке строка. По умолчанию вроде используется из системных настроек. А «u» строка это уже ваши питоновские наслоения.

hibou ★★★★★
()

что-то многовато размахиваний флагом «юникодная строка». юникод юникоду рознь, уточняйте.

k0l0b0k ★★
()
Ответ на: комментарий от hibou

> Я про то, что gchar пофиг в какой кодировке строка.

ну (gchar *my_string) — это ведь и есть байтовая строка?

(причом уже выяснили что весь GTK работает на байтовых стрках в кодировке utf-8 (не юникод))

> А «u» строка это уже ваши питоновские наслоения.

да... верно.. к сожелению не написал в начале темы — что речь сугубо о Пайтоне (просто тэг "[python]" в уголке оставил :-))

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от k0l0b0k

> юникод юникоду рознь, уточняйте.

верное замечание..

под словом Unicode — имеется ввиду строка логически реализованная ввиде массива _символов_ (символов юникодной таблиццы) а не массива _байтов_

как мы знаем в зависимости от различных кодировок (и от разных символов) — символ может занимать разное число байтов

я говорю про такой вид организации юникодной-строки — где независимо от того какойбы был символ, сёравно бы он занимал одну ячейку массива :-)

(ну мне трубно объяснять Сишникам это — ведь у них нет разниццы между «байтами» и «символами» :-/ :-/ :-/ .. )

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

>я говорю про такой вид организации юникодной-строки — где независимо от того какойбы был символ, сёравно бы он занимал одну ячейку массива :-)

Юникод специально разрабатывался с учетом того, чтобы разные символы имели разный размер. Ты хочешь убить весь профит от его использования.

ttnl ★★★★★
()
Ответ на: комментарий от user_id_68054

>я говорю про такой вид организации юникодной-строки — где независимо от того какойбы был символ, сёравно бы он занимал одну ячейку массива :-)

Это UTF-32 надо.

Deleted
()
Ответ на: комментарий от user_id_68054

А что если изменить системную кодировку на, допустим, koi8r. После import gtk, что напечатает print sys.getdefaultencoding() ?

Просто интересно.

hibou ★★★★★
()

>байтовые строки (а не Unicode-строки)

Ололо, байтовые строки. А Юникодные строки тогда какие? Деревянные чтоли?

В GTK используется UTF8. Тоже юникод, но латинские символы представлены одним байтом, а национальные - двумя, например.

yoghurt ★★★★★
()

Прочитал половину полотна и понял, что автор просто не знал о внутреннем устройстве UTF8.

yoghurt ★★★★★
()
Ответ на: комментарий от user_id_68054

>utf-8 (не юникод)

Только больше никому это не говори :)))

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

Угу, я тоже. Потом прочитал вторую половину полотна и понял, что речь возможно идет о замене кодировки по умолчанию, sys.getdefaultencoding().

hibou ★★★★★
()

>что думаете про всё это? :-)

Кто-то не осилил документацию и вброс не удался

yoghurt ★★★★★
()
Ответ на: комментарий от user_id_68054

>имеется ввиду строка логически реализованная ввиде массива _символов_ (символов юникодной таблиццы)

Вы не понимаете разницу между символом, глифом, графемой, кодовой точкой юникода и буквой.

dmitry_vk ★★★
()

Я все-таки склонен думать, что это не грязный хак, а исправление кривого питона. - если у него на utf-8 локали sys.getdefaultencoding() - не utf-8 - это ппц!

А то что ты применяешь 'u' строки как 'b' строки - это чревато глюками твоей программы на неюникодных локалях. Это хреново.

hibou ★★★★★
()

95% отписавшихся нужно уяснить себе, что представляют собой следующие сущности:

  • bytestring
  • unicode
  • encoding

а только потом советовать или критиковать существующие решения.

А пока - незачет.

shylent
()

Это всё фигня. Вот то что в py3k sys.stdout.encoding зависит от локали вот это зло. Лучше бы оно всегда было utf8 кроме случаев когда юзер сам говорит «взять кодировки из локали» итп.

true_admin ★★★★★
()
Ответ на: комментарий от hibou

hibou нацарапал

Я все-таки склонен думать, что это не грязный хак, а исправление кривого питона. - если у него на utf-8 локали sys.getdefaultencoding() - не utf-8 - это ппц!

А ведь действительно ппц!

nkt@arnor ~ % python
Python 2.6.5 (release26-maint, Aug  7 2010, 23:16:53) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getdefaultencoding()
'ascii'
>>> quit()
nkt@arnor ~ % locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=POSIX
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
fat_angel ★★★★★
()

> что думаете про все это ?

Ну горбатого могила исправит.
Нативно, нормальная поддержка юникода в tcl сто лет как есть.

elipse ★★★
()
Ответ на: комментарий от fat_angel

Вы перегибаете.

В python 2.x значение sys.getdefaultencoding() не зависит от локали (по крайней мере, python сам ничего для этого не делает). default encoding - глобальная «настройка», которую можно переопределить в site.py/sitecustomize.py.

Насчет дефолтного значения, - из Objects/unicodeobject.c:

const char *PyUnicode_GetDefaultEncoding(void)
{
    return unicode_default_encoding;
}

void _PyUnicode_Init(void)
{
    ...
    strcpy(unicode_default_encoding, "ascii");
    ...
}

Из того же файла для py3k:

static const char unicode_default_encoding[] = "utf-8";

Вы бы хоть проверяли, прежде чем заведомо ложные сведения постить.

shylent
()
Ответ на: комментарий от dmitry_vk

> Вы не понимаете разницу между символом, глифом, графемой, кодовой точкой юникода и буквой.

не то что бы я не понимаю разниццы — а я вообще из перечиследнных вами слов знаю только слова:
«Вы», «не», «понимать», «разница», «между», «символ», «точка», «юникод», «буква».

:-)

(разниццы между словами «символ» и «буква» — нет не понимаю :))

((мне стыдно да... признаюсь...))

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от true_admin

> Это всё фигня. Вот то что в py3k sys.stdout.encoding зависит от локали вот это зло. Лучше бы оно всегда было utf8 кроме случаев когда юзер сам говорит «взять кодировки из локали» итп.

нет не лучшебы.

в Python3 и в Python2 (там вот именно этот параметр _одинаково_ реализованн) — как раз сделали всё правельно внутри объекта «sys.stdout.encoding»

если вы не понимаете зачем нужен параметр sys.stdout.encoding — то очень собазеную.

и с локалью он никак не связан

а вот sys.getdefaultencoding() — в Python3 сделан лучше чем в Python2

ну для подробных комментариев об sys.getdefaultencoding() — смотрите сообщение: http://www.linux.org.ru/jump-message.jsp?msgid=5454970&cid=5456458 :-)

как видите этот паратерт тоже с локалью не связан

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от hibou

> А то что ты применяешь 'u' строки как 'b' строки - это чревато

глюками твоей программы на неюникодных локалях. Это хреново.


что значит на НЕюникодных локалях?

внутри ЛОГИЧЕСКОГо представления — хочу чтобы было вс в u'...'...

..а когда надо вывести на экран (терминал например, или GUI), или записать в файл — то нада РАЗУМЕЕТСЯ обязательно перевести в байтовое представление (с кодировкой зависящей от локали)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

>ну мне трубно объяснять Сишникам это — ведь у них нет разниццы между «байтами» и «символами»

Пробовал я этот ваш хваленый питон. Юникодные строки — это пиздец. Адов неистовый пиздец. Не стал вникать в детали и просто дропнул эту убогую пионэрскую поделку без обратной совместимости после того, как

$ cat 1.py
#! /usr/bin/env python
# -*- coding: utf-8 -*-

print u'Преведмир!'
$ ./1.py 
Преведмир!
$ ./1.py > x
Traceback (most recent call last):
  File "./1.py", line 4, in <module>
    print u'Преведмир!'
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

В то время как сишка just works as expected.

linuxfan
()
Ответ на: комментарий от hibou

> Я все-таки склонен думать, что это не грязный хак, а исправление

кривого питона. - если у него на utf-8 локали
sys.getdefaultencoding() - не utf-8 - это ппц!

я тоже думаю что это ППЦ... (ппц который исправили в Python-3, но оставили не исправленным в Python-2 :-D)

вот правда я немного не согласен с авторами PyGTK — то что они решили этот ППЦ исправить — вот так в тихую.. ведь нада бы делать такие вещщи согласованно :-)

(и если уж по какой-то (непонятной мне) причине авторы Пайтона решили не исправлять это идиотское поведение Python-2... то видимо была на это какаято причина.. причина непонятная мне но думаю весомая :))

...а-то одна библиотека исправит <такое-то-одно> поведение Пайтона... вторая библиотека исправит <такое-то-другое> поведение пайтона.... и чтоже в итоге получится %) %)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от linuxfan

Так вы прямо и говорите «не осилил». А то там «не хотел вникать в детали», «сишка just works» и т.п.

Не осилили - не страшно. Я думаю, в мире найдется достаточно людей, которые не смогли прочитать полстраницы документации, - можете спать спокойно.

shylent
()
Ответ на: комментарий от linuxfan

> Не стал вникать в детали и просто дропнул эту убогую пионэрскую поделку без обратной совместимости после того, как

а надо было вникнуть :-)

так как в твоём коде ошибка

перед тем как вывести на экран юникодную строку — тебе надо было перевести её обратно в байтовую

import sys
terminal_encoding = sys.stdout.encoding or 'utf-8'
print u'Преведмир!'.encode(terminal_encoding, 'replace')

(и ещё говорю заранее:
а все аргументы командной строки sys.argv — тоже НЕОБХОДИМО переводировать в юнкодные строки — с учотом локали:
args_encode = locale.getdefaultlocale()[1] or 'utf-8'
)

еслиже не хочешь парить мозг с кодировками/перекодировками — то используй Python-3 — он всё делает это автоматом :-)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

Я считаю, что возможность сказать sys.setdefaultencoding() - это уже большая ошибка со стороны разработчиков python, честно говоря. Хотя, скорее всего, у них были на то причины. Какая-нибудь там обратная совместимость, или что-то в том же роде. Впрочем, какая разница.

Надо просто код, работающий с юникодом по-честному писать - получили данные - decode. Вывели - encode. И всем все понятно.

Но вы-то тут не при чем, это, действительно, GTK так извращается.

shylent
()
Ответ на: комментарий от user_id_68054

>print u'Преведмир!'.encode(terminal_encoding, 'replace')

Я уверен, что должен быть более лаконичный способ. Для языка, в котором решено сэкономить на выражении окончания блока, такие encod'ы слишком многословны.

еслиже не хочешь парить мозг с кодировками/перекодировками — то используй Python-3 — он всё делает это автоматом :-)

Я уже выбрал сишку, которая автоматом кладет на кодировки и не отличает байт от символа. Идеологически это неверно, но в 95% случаев адово удобно, а на фоне повсеместного засилья utf-8 вообще шоколадно: пишешь, не думая о кодировках, и все работает.

linuxfan
()
Ответ на: комментарий от shylent

> Но вы-то тут не при чем, это, действительно, GTK так извращается.

одно хорошо —

что данный «хак» не запрещает сделать вид что «хака» как будто бы и нет:

unistr = unicode(my_text_entry.get_text(), 'utf-8', 'replace')

:-)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от linuxfan

Я уверен, что должен быть более лаконичный способ. Для языка, в
котором решено сэкономить на выражении окончания блока, такие encod'ы
слишком многословны.

конешно есть более короткий способ!

например можно заранее исготовить вспомогательную функцию :-):

(или набор функций)

import sys, locale

DEFAULT_ENCODING = 'utf-8'
DEFAULT_ENCODING_ERRORS = 'replace'

def safe_unicode(
            obj,
            encoding=DEFAULT_ENCODING,
            errors=DEFAULT_ENCODING_ERRORS,
        ):
    if not encoding:
        encoding = DEFAULT_ENCODING
    
    try:
        if isinstance(obj, unicode):
            return obj
        elif isinstance(obj, bytes):
            return unicode(obj, encoding, errors)
        else:
            return unicode(obj)
    except ValueError:
        return u'<VALUE_ERROR>'

def safe_bytes(
            obj,
            encoding=DEFAULT_ENCODING,
            errors=DEFAULT_ENCODING_ERRORS,
        ):
    if not encoding:
        encoding = DEFAULT_ENCODING
    
    try:
        if isinstance(obj, bytes):
            return obj
        elif isinstance(obj, unicode):
            return obj.encode(encoding, errors)
        else:
            return bytes(obj)
    except ValueError:
        return b'<VALUE_ERROR>'

def get_app_name():
    # get encoding or 'None'
    encoding = locale.getdefaultlocale()[1]
    # get first arg as bytes in system encoding
    app_name_b = sys.argv[0]
    
    app_name = safe_unicode(
        app_name_b,
        encoding=encoding,
    )
    
    return app_name

def get_args():
    # get encoding or 'None'
    encoding = locale.getdefaultlocale()[1]
    # get args as bytes in system encoding
    args_b = sys.argv[1:]
    
    args = [
        safe_unicode(
            arg_b,
            encoding=encoding,
        )
        for arg_b in args_b
    ]
    
    return args


def safe_print(*args, **kwargs):
    fd = kwargs.get('file', sys.stdout)
    encoding = getattr(fd, 'encoding', None)
    
    args_b = [
        safe_bytes(arg, encoding=encoding)
        for arg in args
    ]
    
    print(*args_b, **kwargs)


user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от linuxfan

> Какой «такой же» и причем тут dvcs?

не не.. не обращайте внимания на то что bzr это dvcs ..

..я просто имею ввиду что bzr — это программа написанная на python (Python-2)

..причём bzr отлично поддерживает non-ascii :-) [даже в терминалах на венде :-)]

вот сделайте какоенить действие связанное с выводом non-ascii строчки на экран — и перенаправьте поток в файл .

bzr это сделает (как и любая другая качественная программа :))

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Хм, ну тут смотря как посмотреть, видите ли.

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

Картину во многом портит тот факт, что utf-8 обратно-совместим с ascii. Из-за этого неправильно написанный код до последнего момента может делать вид, что работает.

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

Поэтому нужно перестать надеяться на то, что все будет работать «автомагически», а просто сразу писать хороший код. Если все как следует структурировать, то там не так уж и много этих encode/decode придется написать.

Не по теме: в том же Qt в документации настоятельно рекомендуют явным образом работать с кодировками. см. QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, QT_NO_CAST_FROM_BYTEARRAY.

shylent
()
Ответ на: комментарий от shylent

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

Вы обкурились? Для этого в незапамятные времена была придумана такая штука, как локаль. А разработчик нихрена не знает, знаю только я как пользователь (и устанавливаю локаль исходя из этого тайного знания). Впрочем, теперь понятно, почему периодически попадается питоноговноподелия, использующие невнятные кодировки (cp1251, например) вне зависимости от текущей локали.

kemm
()
Ответ на: комментарий от kemm

>Для этого в незапамятные времена была придумана такая штука, как локаль.

...которая безбожно просасывает в наши дни. Например, не так давно firefox пытался воспринимать url, переданный в командной строке как строку в кодировке текущей локали. pidgin же в свою очередь url'ы вида http://ru.wikipedia.org/wiki/Статья честно передавал «как есть» в виде последовательности байт. Угадай, какую страницу я видел, когда кликал по этой ссылке? И чем мне поможет локаль в этом случае? Да и вообще, какое разумное решение может быть у этой проблемы?

linuxfan
()
Ответ на: комментарий от kemm

Причем здесь локаль? Если вам данные приходят «из сети», допустим, то какое отношение к этому имеет локаль? Я же написал - «в общем случае».

Собственно, python тут даже и не при делах совершенно. Плохой код, «использующий невнятные кодировки», можно написать на любом языке.

Придирайтесь уж по делу, если так хочется поспорить.

shylent
()
Ответ на: комментарий от shylent

> Причем здесь локаль? Если вам данные приходят «из сети», допустим, то какое отношение к этому имеет локаль? Я же написал - «в общем случае».

В общем случае разработчик нихрена не знает. В частных случаях, как, например, получение данных по сети в рамках какого-то протокола - знает. Что тебе не так-то?

kemm
()
Ответ на: комментарий от shylent

Я не про то говорю, вы меня все не понимаете(хнык).

laptop:/tmp$ export LC_ALL=C
laptop:/tmp$ python ./test.py 
тест
laptop:/tmp$ python3 ./test.py 
Traceback (most recent call last):
  File "./test.py", line 2, in <module>
    print("\u0442\u0435\u0441\u0442")
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128)
laptop:/tmp$ 

Это нихрена не нормально. Проги не должны вот так вот падать. Во 2-м с этим было сильно лучше. Уж хотя бы документировали что когда скрипт из-под крона запускаешь с локалью C то всё может с пол пука упасть.

true_admin ★★★★★
()
Ответ на: комментарий от linuxfan

> Например, не так давно firefox пытался воспринимать url, переданный в командной строке как строку в кодировке текущей локали. pidgin же в свою очередь url'ы вида http://ru.wikipedia.org/wiki/Статья честно передавал «как есть» в виде последовательности байт

Представь, что они оба ещё бы хвост на локаль клали, и фырефокс читал бы урл как koi8-r, а пиджин передавал как cp1251 при том, что в системе сплошной utf8? 8))

Угадай, какую страницу я видел, когда кликал по этой ссылке? И чем мне поможет локаль в этом случае? Да и вообще, какое разумное решение может быть у этой проблемы?

А я хз, что там у вас криво работает. 8)) В кошерном KDE при клике на http://ru.wikipedia.org/wiki/Статья в копыте - в конквероре открывается http://ru.wikipedia.org/wiki/Статья. Возможно, я зажрался, но мне такое поведение кажется логичным... 8))

Единственное разумное решение - использовать локаль. Если кто-то что-то на неё кладёт при чтении из файла/stdin/обработке аргументов - ССЗБ. В сеть надо отдавать в той кодировке, которую ожидают увидеть на том конце.

kemm
()
Ответ на: комментарий от anonymous

>ведь функция sys.setdefaultencoding(...) [ http://j.mp/92lnL6 ] — не

работает %) %)



http://doweb.sloyko.com/index.php?/archives


/22-Strah_i_nenavist_setdefaultenc... [ http://j.mp/aeDq4E ]



о спасиб, большое!

способ:

import sys
reload(sys)
sys.setdefaultencoding('utf-8')

 — работает!

...

теперь я могу сам делать эти Хаки :-) :-D

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от true_admin

>

laptop:/tmp$ export LC_ALL=C
laptop:/tmp$ python ./test.py 
тест
laptop:/tmp$ python3 ./test.py 
Traceback (most recent call last):
  File "./test.py", line 2, in <module>
    print("\u0442\u0435\u0441\u0442")
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128)
laptop:/tmp$ 

> Во 2-м с этим было сильно лучше.

вы сравнили в Python2 и Python3 совершенное _разные_ программы..

в Python-2 — строковая константа — была байтовой, но в Python3 вы уже зачемто решили вывести на экран юникодную строковую константу...

...кстате биру назад свои слова где я говорил что в Python3 всё делается автоматом.. таки значит тоже не автоматом :-(

[это значит что Python3 не сильно лучше чем Python1... но по крайней мере точно не хуже]

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

простите.. опечатался.. python2 а не python1... конешноже :-D :-D

user_id_68054 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.