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

Не все прочитал, но мне кажется, это питон головного мозга.

Учи лучше Си.

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

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

Учи лучше Си.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А чем плох UTF-8, лежащий в байтовом массиве, для хранения и обработки строк?

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

Это UTF-32 надо.

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

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

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

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

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

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

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

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

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

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

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

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

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

>Это UTF-32 надо.
Смотря что под символом понимать. В юникоде полно комбинирующих «символов».

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

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

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

• bytestring
• unicode
• encoding

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

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

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

Это коню понятно.

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=

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

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

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

В 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";

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

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

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

:-)

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

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

> Это всё фигня. Вот то что в 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 :-)

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

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

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

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

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

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

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

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

$ 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.

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

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

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

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

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

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

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

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

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

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

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

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

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 — он всё делает это автоматом :-)

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

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

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

проведите такойже эксперимент с программой bzr

как думаете — загнётся ли она на вашем тесте? :-)

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

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

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

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

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

одно хорошо —

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

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

:-)

>проведите такойже эксперимент с программой bzr

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

Я уверен, что должен быть более лаконичный способ. Для языка, в
котором решено сэкономить на выражении окончания блока, такие 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 то всё может с пол пука упасть.

> Например, не так давно 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/обработке аргументов - ССЗБ. В сеть надо отдавать в той кодировке, которую ожидают увидеть на том конце.

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

http://doweb.sloyko.com/index.php?/archives/22-Strah_i_nenavist_setdefaultenc...

>ведь функция 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

>

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... но по крайней мере точно не хуже]

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