>> в котором не хочется исправить какой-то идиотизм и т.п.
> Вот почему-то в некоторых языках вопрос оказывается таким, а в некоторых --
> нет.
> По мотивам Вашего с Ф.Ф. обсуждения могу отметить, что изменение _семантики_ API
> без смены имён -- это идиотизм в мозгах разработчиков, обычно неисправимый. В случае py2->py3 нет проблем (только затраты) на переход поэтапно, если сделать эти самые промежуточные версии. Например, с таким планом:
2.8: выпускаем версию со штатными алиасами listkeys для keys и т.п. для dict; совместимость 2.7+2.8 - использование старых имён; за время работы с 2.8 ожидаем мягкий перевод на новые имена;
2.9: сохраняем это, но объявляем deprecated старые имена; за время работы с 2.9 ожидаем замену d.listkeys() -> list(d.keys());
2.10: listkeys() отменяется; keys() переключается на выдачу итератора; все плавно меняют iterkeys -> keys;
2.11: алиасы типа iterkeys отменяются (где-то тут можно слиться и с 3-й веткой).
Аналогично по всем остальным фичам (bytes/unicode, имена модулей, etc.) - кажется, 4 версий хватит на мягкий переход по стандартным принципам.
С таким планом я лично не против поэтапной смены в том числе и со сменой семантики уже известных имён, при выполнении условия, что финальная версия будет более устойчива.
Модуль six делает что-то похожее, но более топорно и дорого в рантайме.
> Такое же студенты учинили с пресловутым apache2 (точнее, apr) --
> были секунды, стали миллисекунды, подумаешь.
> Т.е. когда люди и сами не пользуются, и не представляют, каково это
> вообще -- плодами их трудов собственно пользоваться.
При резком рывке - я согласен с тобой. При проработанном плане миграции - можно действовать по этому плану.
