>> Смотря что за библиотека. Не так давно был свидетелем и активным
>> участником перевода на py3 ряда проектов с scipy.org (раньше использовали 2to3).
>> Абсолютно ничего страшного.
> Это не показательный пример потому, что на scipy очень мало работают со
> строками, а там, где работают - мало проблем кодировок и т.п.Чиво? Там дофига работы со строками. ipython - так просто интерактивная оболочка для Python.
> А вот мой пример - работа с протоколами SIP, Radius... Они текстовые
> или передают много текстовых строк, а конверсия в юникод 1) нафиг
> не сдалась, 2) дорогая и медленная. Это значит, что мне практически
> во всём коде придётся текстовые константы оснастить префиксом "b". Это изменение
> практически всего кода, причём автоматизации через 2to3 не поддаётся, потому что
> эта автоматизация не предполагает автоматическую замену старого str на bytes, как
> должно было быть для действительно правильного исполнения.
Если эти изменения действительно масштабные - вам надо хорошо подумать головой над реорганизацией кода.
>>>>Он не просто "говорит", он объясняет почему. Вы можете это объяснение процитировать?
>>> Зачем?
>> Затем, что вы с ним не потрудились ознакомиться. И/или - не
>> поняли.
> А, может, понял? Я, думаю, понял - с мультитредингом работаю давно. Но
> *поверил* ли я?
> Почему у JVM, .NET машины нет таких проблем и они не плачутся
> на то, что не могут держать один лок на всех?
Может потому, что эти VM купились на модное сование тредов во все дырки?
>> Вперед:
>> http://www.python.org/dev/peps/pep-0001/#submitting-a-pep
>> А то решателей - вагон, а конкретных решений так и не видно.
> Ага, это уже началось стандартное "Сперва добейся". А почему мы, пользователи, должны
> это решать?
Потому что вам никто ничего не должен. Раз решений так и не появилось - это лишнее свидетельство того, как оно "надо".