>>34070 Я бы посоветовал не давать дурацких советов, потому как все, кто может, используют 3-й, но не все, видишь ли, могут, и по вполне реальным причинам. Новички же банально ссут. Короче, не можешь подсказать, так и не выёбывайся, Склифосовский. Хотя ссылку ты ему дал нормальную, да.
>>34069
#!/usr/bin/env python
# -*- coding: utf-8 -*-
txt = raw_input().decode('utf-8')
print 'Lower: ', txt.lower()
Консоль: sakura, кодировка консоли utf-8. Как видишь, всё работает. Другое дело, что, вообще говоря, не лучшая практика. полагаться на то, что кодировка консоли именно utf-8, но, как я понимаю, тебя сейчас не это волнует.
Обрати внимание на вторую строчку кода, она важна, если в теле скрипта есть захардкоженые не-ascii строки.
Что тебе нужно понять: букв нет. Есть последовательности байтов и то, как их интерпретировать, определяет кодировка. u"" это не строка в кодировке utf-8, это строка юникода, что является совершенно отдельной абстракцией.
Читать:
Разница между вторым и третьим пайтоном в этом плане в том, что во втором дефолтная строка — это байтовая строка, а в третьем — юникод строка. Таким образом, второй пайтон как бы всё технически в работе со строками умеет, но многие АПИ просто не умеют работать со строками в нужной кодировке, а в третьем об этом заботиться не нужно, ибо абстракцией по умолчанию является юникод, а не байтовая строка.
Читать (по желанию):
http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/ В принципе, советую отказаться от привычки задавать подобные вопросы здесь и при каждой отдельной проблеме гуглить и первым делом кликать по ссылкам на стаковерфлоу. Здесь ты в большинстве случаев получишь бесполезный ответ, и вообще, это нормальный способ решать подобные проблемы, тем более, что проблемы кодировок во втором пайтоне хорошо озвучены в сообществе. Но это, конечно, твоё дело.
Алсо, да, впредь, пожалуйста, используй более точные формулировки, чем "огромная куча проблем". "Огромная куча проблем" не является удовлетворительным идентификатором.