1. Почему в "сырых" строках работают юникодовые последовательности, хотя байтовые не работают? Не совсем они, получается, "сырые".


2. 
Почему так?

А с чего ты взял что работают?
r"\User" - никаких ошибок, Python второй ветки создает str, длина 5 символов (обратный слэш - отдельный символ, как и ожидалось). В Python 2.x символы - однобайтовые, соотвественно это просто 5 байт подряд.
Обрати внимание, что r"\User" и "\User" - в данном случае одинаково, потому что управляющей последовательности \U в питоне нет.
А вот потом уже буквой u ты просишь его создать из объекта str объект unicode, причем заставляешь использовать raw codec.
Raw codec подразумевает, что последовательность "обратный слэш U четыре числа" будет перекодирована в один символ. Вот он и старается тебе перекодировать, но естественно ничего не выходит.
Если стоит задача перевести в юникод сочетание "обратный слэш User", то можно воспользоваться unicode(r'\User') - тогда подразумевается не создание строки unicode из группы байтов, а именно конвертация одного вида кодировки в другой.
В то же время ur'\u0410' ошибки не вызовет, это соответствует символу кириллицы "А"

И вот здесь переходим к второму вопросу. Если при создании ur'\u0410' ошибки не будет, то она запросто может появиться при отображении.
Дело в том, что python использует ascii по умолчанию для вывода и для ввода, а в ней просто нет такого символа ( http://www.asciitable.com/ ). Поэтому при попытке перекодирования строки "ф" в ascii, и здесь возникает исключение. Но ничто не мешает тебе сохранить например эту строку в файл, присвоить другой переменной, отдать в браузер пользователя если это например django и так далее.

Касательно твоего второго примера. Интерактивный шел питона использует локаль по умолчанию, для русской windows это Windows-1251. А функция unicode рассчитывает что ей подадут строку в кодировке по умолчанию, то есть ascii. Нужно прямо указать кодировку исходника, например unicode(x, 'Windows-1251')

Более четко можно посмотреть здесь, даже примеры похожие:
http://docs.python.org/howto/unicode.html#...unicode-support






Это сообщение отредактировал(а) VinniPuhh - 15.5.2012, 17:38

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

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


А не cp866 в консоли?
Тут немного неудобно как-то, неужели питон сам не знает кодировку своей сосноли?

Може ты и прав, може и cp866 - не уверен насчет именно 1251



Не то чтобы "своей", скорее системной (stdin/stdout). 
По идее да, можно было бы системным API выяснить какая там кодировка по умолчанию.
Я думаю что разработчики не сделали такого, чтобы избежать проблем при конструкциях
myprg.exe file1 > pyhton myscript.py
и тому подобным.



А вот тут (естественно imho) ты в корне не прав по идеологии. Ты  задаешь литерал, значение которого используется в программе.
Посмотри с точки зрения интерпретатора: Как понять, что именно (в байтовом представлении) ты имел в виду?
Логично есть такие пути:
 1. Задавать литерал явно в байтовом представлении  (\u0514\u0213\u2231)
 2. Указать явно, каким образом переводить набранное в редакторе в это представление (# -*- coding: utf-8 -*-)
 3. Запретить набирать в редакторе неоднозначные символы (SyntaxError: Non-ASCII character '\xd1' in file test.py on line 1, but no encoding declared;)
 4. Договориться, что всегда использовать определенный алгоритм перевода. (Пока в сообществе Python не договорились  )

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

Я бы решал вопрос так:

Мы друг друга не поняли, я имел в виду указывать в unicode() вторым параметром кодировку файла. Указывать в файле кодировку считаю - правильно, хорошо бы жавоидам это перенять.




Сам переправил? 


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

Кстати, в 3.х стоковые литералы по умолчанию юникодные. Решает много проблем. И вообще, в 2.х юникод - больное место. Видите ли, в 2012 году, когда даже линупс юникод осилил, а 9х уже похоронили, программы не работают, если пути, где лежат они или файлы, с которыми они работают, содержат не-аски символы. А все потому, что у девелоперов все работало.


Не, я в курсе, что так можно, но я ничего эскейпить не хочу.

Короче, баг налицо, вопрос, будут ли его править. В 3.х, говорят, все работает.