Pull to refresh

Comments 31

TL;DR: На 2 версии всё ещё много нужных пакетов, а корпорации боятся взорвать прод на регрессе.

Если честно, слишком много воды и мало конкретики.
Позволю себе расширить ваш tl;dr:

— стата по PyPI
— кейс Fb
— вопрос совместимости ОС
— кейс Red Hat
— критика новинок в python 3
— 2to3 и six

И потом уже (понятно, что проблема общая):
корпорации боятся взорвать прод на регрессе
UFO just landed and posted this here
Золотое правило: работает — не трогай.
Был у меня проект, внутренняя erp, написанный ещё на php4, обновление на 5ку он прошёл и не заметил, а вот на 7ку не одолел. Неделю накликивал сценарии для тестирования, а сам апдейт с фиксами занял меньше 2 дней и это с php 4 на 7.

Из личного опыта, мои сервера на Python все живут в микросервисных облачных платформах сейчас.
В случае с AWS Lambda миграция с Python 2 на 3 прошла хоть и не без приключений, но относительно быстро — разве что средство развёртывания пришлось сменить и доработать.
А вот с AppEngine SE переход оказался очень болезненным — многие привычные библиотеки и службы от Гугла просто перестали поддерживаться или безбожно глючат и тормозят.


В итоге миграция Питона с 2 на 3 часто выливается ещё и в дорогостоящее, навязанное извне технологическое перевооружение, причем не приводящее к какому-то заметному улучшению качества жизни пока что.

Мне одному показалось, что на второй картинке код на PHP?
Еще и каким-то боком к WordPress, видимо.


Я не спец по PHP, сам питоном пользуюсь, поэтому несколько обескуражен.

Эта ситуация напомнила старый анекдот.
Партийный лектор выступает в сельском клубе: "… И вот, товарищи, наше советское общество одной ногой прочно стоит в социализме, а другой уверенно шагнуло в коммунизм!"
Голос из зала: «И долго мы так враскоряку стоять будем?»

Лично меня и мою контору Django 2.2 вынудила дропнуть Python 2.7. Но пока не дропнули, казалось, что преимуществ особо нет, а поддержки маломальски адекватного Python 3.5 (а лучше 3.6) не было в большинстве дистрибутивов, используемых заказчиками.
Но сократив поддержку до 3.5 и поработав так полгода, хочется подняться уже до >=3.6. Куча костылей просто отсеялось, анотации вдохнули жизнь в IDE, избавились от части кода и его тестов. Теперь облизываемся на f-strings и поддержку async (из коробки). С чем-то пришлось расстаться, но ни разу не пожалели.
Да, наши проекты в среднем 10к строк. Это немного, но и команда у нас не 10к единиц.
Правда всё равно хочется адекватного LTS в языке. Я понимаю тех, кто остаётся на 2.7, потому что ему замены нет, ведь новые версии Python'а не имеют длительной поддержки, но, справедливости ради, не ломают старой функциональности (обычно).
Короче говоря legacy — зло (да, капитан), но хотя нет LTS, двигаться дальше надо.

о необходимости обратной совместимости для языков, о которых заявляют как
" промышленные" уже упоминали? проблема вечная, а питон подзабил на это в свое время.

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

и надо отдать должное — разработчики питона в данной ситуации повели себя хорошо — держались почти до последнего. столько лет тянуть поддержку 2.7 — честь и хвала.

рубисты вон, помнится, как то раз просто плюнули на всех кто не смог перехать на новую версии — причем почти сразу, на горизонте трех или около того лет.

а питонисты — молодцы. но увы. неумение в свое время обеспечить обратную совместимость наконец ударило по тем, кто много лет назад поверил молодым питон-программистам с горящими глазами и принял решение разработки больших систем питоне.

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

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

что ответит питон 3 на такого рода запрос? есть ли полная подробная спека эталонного поведения языка? достаточно ли ее для того что бы сделать автоматические тесты, которые позволят проверить насколько «интерпретатор питона от васи пупкина» соответствует эталону? или насколько новая версия интерпретатора соответвует эталону старой?
Первая версия Python 3 вышла почти 11 лет назад. Python 2.7 вышел годом позднее. Не многие современные решения с LTS предлагают 10-летнюю поддержку. По моему претензии к обратной совместимости и хотелки LTS уже поздновато высказывать. Заявления, подобные вашим, могли быть актуальны лет 6-7 назад, но не сейчас. За 11 лет существования Python 3 можно было сто раз пошевелиться и начать планомерно, а не в авральном режиме, готовить свой код к переходу на новую версию.
я не про авральный режим.
я про то, что переписывать большую систему, даже в планомерном режиме — на плохо-совместимую новую версию языка — дело очень дорогое.

и отсутствие эксцессов вида «денежные затраты, только потому что создатель языка решил впилить пару новых фишек» — это первейшее требование бизнеса к промышленному языку.

если вы пишете «промышленный», сложный код который будет работать ОЧЕНЬ долго — стоимость работ по переводу системы на версию языка, которая потеряла обратную совместимостиь — начинает составлять очень значительную часть бюджета.
и платить за это никто не готов.

и вопрос не в плановости или авральности. вопрос в том что это дорого. очень дорого.
потому, имхо, во многих случаях, говорить о переводе систем на питоне 2.7 на питон 3 — не приходится. никто за это платить не будет.
и в 20м году их будут попросту отключать, выводить из эксплуатации и заменять на другие. возможно и вероятно не на питоне написанные.

____________________________________________________
ладно. питон 2.7 -> 3 показал как не надо делать обновы, и ладно, дело прошлое опять вспомню про руби тоже пару раз давшему маху… тоже в прошлом.

но что же с питоном 3?

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

когда я буду выбирать средства реализации для новой системы — что мне показать в аргументах? или сразу писать, что «ежегодно, на перевод на новые версии питона у вас будет уходить ~20% из бюджета поддержки системы??»

20% — цифра, конечно, с потолка, — но она есть, и вопрос в том что делается, что бы ее минимизировать?

offtop: можно для сравнения пообсуждать, что можно делать (и что делается) для этого на примере java, но тред же про питон?

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

В этом я с вами полностью согласен.

Я как раз и говорю, что новые фичи вобще являются несущественным фактором для промышленного языка. Существенным является что бы поведение системы не менялось при переводе ее на новый интерпретатор/компилятор/платформу, и не требовалось менять код для такого перевода.

Более того, я считаю, что проблема EOL средств разработки для больших систем гарантированно наступает. (какой бы не был LTS длительным — он кончится).

И _единственный_ путь по предотвращению проблемы окончания EOL — это обеспечение обратной соместимости между версиями языка, когда новая версия пусть и добавляет новвые фичи, но гарантирвоанно не меняет поведение старого кода.

Вот я и пытаюсь узнать — что делается создателями питона 3, что бы помочь избежать проблем связанных с EOL?

Обратную совместимость нельзя поддерживать бесконечно. Также есть хорошие архитектурные решения, а есть не очень. Обратная совместимость подразумевает, что поддерживать и тащить в новую версию придется всё. А это увеличивает время на поддержку, сложность системы и неоднозначность, когда несколько решений, обеспечивающих один и тот же функционал, живут параллельно. Мое мнение — ломать обратную совместимость необходимо для прогресса, лучших решений и эволюции языка. Но переход на новую версию должен быть как можно ещё проще. Иначе получится, как с JavaScript, в котором некоторые неудачные решения живут уже не один десяток лет только потому, что иначе все сломается.

вы меня простите, но вы, имхо, по прежнему мыслите категориями «давайте сделаем наш инструмент красивым».

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

вы ставите во главу угла некий «проресс», кстати не детализаруя что это конкретно значит, а бизнес задается вопросом: «а сколько денег будет стоить этот прогресс» и «кто конкретно за это будет платить»?

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

— Обратную совместимость поддерживать, имхо, можно, достаточно долго, сильно больше чем любая LTS; хотя и при соблюдении ряда условий:

1. во перых требуется автомтический контроль за этой совместимостью (читай автоматические тесты валидности интерпритаторов/компиляторов под каждую версию). иначе как эту совместимость действительтно проверять?

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

не к ночи будет сказано, но у джавы и джаваскрипта такие спеки есть.
и есть альтернативные реализации, и процессы валидации/тестирования/проверки сторонних интерпритаторов тоже есть. и джава и а 13й версии продолжает поддерживать работоспособность версии 1.

у питона есть такое? а когда появится?
есть альтернативные реализации, совместимые с исходным стандартом?

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

— вот я и спрашиваю: питон 3 — это всё еще экспериментальный язык, для небольших систем со сроком жизни полгода-год, «с новыми фичами» и с «правильной по последнему слову архитектурой», которая целенаправленно и осознанно ломает обратную совместимость ради новых фич…

или это уже язык, претендуюший на звание «промышленный язык» — язык, в разработку кода на котором бизнес может вкладываться на горизонте более 5-10 лет, не боясь, что в какойто момент, все то, что было создано перестанет работать, потому что версия языка перестанет поддерживаться?

это не к рассуждениям плохо-хорошо.

это к позиционированию, и осознанию места и ниши языка, границ его применимости, внушения толпам молодых красноглазых неофитов/фанатиков правильного понимания о том, «где это можно применять».

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

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

питон 3 готов стать чем то иным?
Не прощу) Потому что про красоту я не писал, вы сами это придумали. Писал я про эволюцию. А это совсем другое. Например, изменение существующих решений. Пример я уже привел про строки в юникоде. Если ваш бизнес не готов вложиться в переход на новую версию, можно сидеть на старой, никто ее не ломает, работать она будет, пока ваш проект на ней живёт. Если же вы хотите получать новый функционал в языке, меньше ошибок и уязвимостей в том же интерпретаторе, то бизнес должен понимать, что это не всегда нахаляву дается. Иначе берите JS, на нем сейчас чего только не пишут. Там обратная совместимость практически 100%, со всеми вытекающими.
про красоту я не писал, вы сами это придумали. Писал я про эволюцию. А это совсем другое. Например, изменение существующих решений. Пример я уже привел про строки в юникоде.
как эта «эволюция» помогает бизнесу эффективнее выполнять производственные функции?

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

а переход на юникод понизил расход ресурсов? опять же, утрируя — нет.

а «про юникод» бизнес вас вообще спросит: а почему вы сразу так не сделали? а когда вы разведете руками — запишет в графе «минусы»: "принимали необдуманные рещения, теперь просят с нас денег на перевод системы на вовую версию питона исправление своих ошибок в прошлом".

понимаете? во главе угла не эволюция ))) во главе угла сохранение работоспособности и минимизация расходов.

Если ваш бизнес не готов вложиться в переход на новую версию, можно сидеть на старой, никто ее не ломает, работать она будет, пока ваш проект на ней живёт


в этой фразе нет проработки рисков.

бизнес не может (вернее здравомыслящий бизнес не будет) сидеть на неподдерживаемой версии языка/системы, потому что в этом случае, все риски и ответственность связанные с ошибками в платформе/sdk/языке и убытками в следствии этих убытков — лягут на плечи подразделений этого самого бизнеса. а это никому из здравомыслящих менеджеров не надо — никто не хочет быть «виноватым без вины».

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

но! повторюсь, что переход на новые версии языка, с целью сохранения поддержки — может быть крайне дорогостоящим предприятием в случае поломки совместимости. в итоге, такую постоянную гонку с переходом на новые версии можно похволить себе только для небольших систем.

Если же вы хотите получать новый функционал в языке,…
вы продолжаете мыслить не теми категориями.
«бизнесу» — глубоко все равно какие там функции в языке.
… меньше ошибок и уязвимостей в том же интерпретаторе, то бизнес должен понимать, что это не всегда нахаляву дается
никто не говорит про халяву. но затраты бывают разные

есть одна стоимость техподдержки, она линейна от времени.

и есть другая стоимость — стоимость по переработке системы на новую версию платформы/языка. и это требуется выполнить что бы иметь возмодность заплатить за первое. и эта стоимость растет нелинейно от объема кода.

а новые фичи языка — бизнусу побоку. не нужно ему это.
ему нужны функции в производственной системе.

имхо, самый большой риск бизнеса связанный с it: это остаться в ситуации, когда производитель больше не оказывает услуг по техподдержке старых версий (не на кого переложить ответственность), а пересаживать систему на новую версию языка крайне затратно, потому что они вкладывались в разработку системы последние лет 5, и они стала очень большой.

и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS ( который, как было описано выше — не очень сильно помогает на большом сроке )?
Иначе берите JS, на нем сейчас чего только не пишут. Там обратная совместимость практически 100%, со всеми вытекающими.
вообще, js плохо подходит для больших систем, в следствии динамической типизации.

опять же вспомню про создателей node.js, которые (честь и хвала им) осознали это достаточно быстро, и пересаживают всех на typescript. но, имхо, им этого тоже не надолго хватит, потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js». потому js — нет, не подходит для сложных систем.

> в этой фразе нет проработки рисков.

Ну плохой у вас управленческий состав, если вы риски не проработали и взяли питон для разработки системы, не понимая, что придется вкладываться в переход на новую версию. А это стало известно ещё 10 лет назад.
Вы поймите, в опенсорсе никто никому ничего не должен. Хотите поддержку, форкайте питон и пилите свой интерпретор с блэкджэком, но уже за деньги. Питон вам, как бизнесу достался бесплатно, инструменты типа всяких фреймворков — тоже. А тут, видите ли, новую версию выпустили, а старую больше 10 лет не хотят поддерживать, вот негодяи. В опенсорсе любой инструмент может перестать поддерживаться. И если вы, как бизнес, выбрали его, но не заложились в эти риски, ну, плохо значит свою работу сделали.

> вы опять мыслите не теми категориями.

Это у вас почему-то нет связи между новым функционалом, который может принести профит вашему бизнесу. Например, asyncio, может ускорить операции значительно, приложение будет решать больше задач в единицу времени (а может и что-то, что ранее вы вообще не могли реализовать из-за низкой производительности потоков, например). Или тайпинги, которые могут сделать вашу кодовую базу стабильнее за счёт внедрения чекера. Меньше времени на исправление багов из-за неправильных типов — больше времени на разработку новых фичей. Или значительно меньшее потребление памяти при использовании словарей. Например, ваше приложение требовало 10гб оперативы, а в новой версии будет требовать 5гб к примеру. Экономия на железе.

> и самый большой риск бизнеса связанный с ит: это остаться в ситуации, когда производитель больше не оказывает услуг по техподдержке старых

Это опенсорс. Когда вы берете опенсорсное решение, вы должны понимать риски. Если нет, ну решение тут непричем.

> и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS

Не знаю) Вы как человек от бизнеса, не проработали этот вопрос, когда решили его использовать?

> вообще, js плохо подходит для больших систем, в следствии динамической типизации.

Внезапно, Питон тоже язык с динамической типизацией, только строгой.
Это опенсорс. Когда вы берете опенсорсное решение, вы должны понимать риски. Если нет, ну решение тут непричем.
ну, ну… не смешивайте опенсорс и бесплатность/отсутствиеподдержки.

скажем так, Java — тоже сейчас опенсорс.

но можно заказать официальную коммерческую поддержку. а в связи с обновлениями лицензий оракла — еще, и обязаны, если у вас не openJDK.

Не знаю) Вы как человек от бизнеса, не проработали этот вопрос, когда решили его использовать?
я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон. и не советую питон в иных ролях кроме как скриптование мелких одноразовых задач. но некоторые заказчики находятся в таком диком убеждении что на питоне можно всё и вся, и для всего пригодно, так свято верят,… что я подумал — «может я что забыл ?»…

Внезапно, Питон тоже язык с динамической типизацией, только строгой.
всё лучше, чем те безобразия как у js или руби )))

и кажется же, что были разговоры про введение статической типизации?.. писал на питоне совсем давно, еще когда только третий был в самую новинку. подумал, может что изменилось. хотя бы методически — описание, стандарт внятный как у js например может появился… <_<
или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…

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

спасибо за диалог.

> я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон.

Тогда не понимаю, чего вас так бомбит от этой новости) Если вас бизнес заставляет использовать Питон, «потому что модно», а вы не хотите… Ну тут я вижу 2 варианта: сменить заказчика или объяснить риски и переложить эти риски на бизнес, а не бомбить почем зря. Да, есть такой нюанс про отсутствие полной обратной совместимости в Питон. Надо это учитывать, а не жаловаться на ее отсутствие)

> и кажется же, что были разговоры про введение статической типизации?..

Не было таких разговоров. Реализация статической типизации в Питон потребует не только переписывания всего интерпретатора (я про CPython), но и всех проектов, что на нем написаны. Да и не нужно это никому, это один из плюсов Питона. Хотите статическую типизацию, берите Java, зачем вам Питон в этом случае, мне непонятно.

> или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…

Уже все давно придумано и к Питону не имеет отношения. Это фундаментальные знания, не зависящие от языка. Почитайте «Рефакторинг. Улучшение существующего кода» от Мартина Фаулера.

> как минимум для меня, снова закрыт.

Ну слава богу)

И вам не хворать)
> потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js»

Есть горизонтальное масштабирование. Node.js в этом плане хорошо масшабируется в виде отдельных процессов) Я вот знаю компанию израильскую компанию Hola, у которых критичные сервисы на JS и достаточно успешно)

Кстати, выделение байт в тип, отдельный от строк, а также все строки в юникоде по умолчанию — одно из самых правильных и удачных решений в 3 версии. Сохранив обратную совместимость, этого бы не удалось сделать

вдумчивое отношение (см ответ выше) — оно включает в себя и выбор базовых решений. опять же, не к ночи, джава от рождения (кажется) была (почему то?) юникодной ( или если это появилось потом — то, кажется, не поломало обратной совместимости ).

с выделение байта в тип — мне прокомметировать сложнее ( не так хорошо знаю питон) но опять же в джаве вспоминается трюк с boxing-unboxing для простых и объектных типов.

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

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

и, увы, имхо, то что вы восхваляете как правильное и хорошее в 3м питоне — это, хотя и действитеьно (верю вам) правильное и хорошее, но это прямое следствие необдуманных решений при создании первоначального стандарта языка; а ситуацию из топика — мы имеем в виду «наплевателского» стиля при введении новых фич. имхо.

хотя, иногда такое наверное и надо делать. если вспомнить преход с Qt3 на Qt4 — это было действительно правильно. троллтечю пока еще были троллтечами, вообще с нуля переписали весь апи, получилось очень стройно, удобно и красиво. но, ВАЖНО, что у систем на базе C++/Qt и срок жизни куда менее чем 5-10 лет. ни о какой долгосрочности или громадности систем речи нет.
Не используйте питон) Используйте джаву, там же все изначально хорошо спроектировано. И будет вам счастье)
Буквально недавно вылез такой баг при переходе на py3: в коде происходил экспорт данных в Excel (неавжно), и в одной колонке строковые значения типа «56_123432_343345» превратились в числовые (56123432343345). Оказалось, в коде выполнялось преобразование в int, и в py2 int(«56_123432_343345») выкидывет исключение, и сохранялся строкой, а в py3 — все ок, int(«56_123432_343345») возвращает 56123432343345.

Это не баг языка, это у вас в программе баг. Нельзя так строки в числа приводить. Есть же isdigit

Мы сейчас в состоянии «100% переведено на Py3, пройдено 99.5% тестов» и не хватает одного зелёного свистка, чтобы переключить интерпретатор клиентам. И то, 0.5% непройденного теста это неустойчивые обгоны, вызванные, похоже, спецификой шедулера Py2.7, который не давал в них войти.

Впечатления от перехода: в общем не всё так страшно. Но:

Без six.py переход невозможен (и то — мы добавили свой six_local на несколько сущностей типа next_method_name и all_string_types, и расширили копию six.py на размещение unittest.mock). Если бы авторы Python выпустили какие-то постепенные переходные версии, то можно было бы обойтись, но при резком различии между 2.7 и 3.x — никак.

Переход на версии до 3.3 даже в этом случае утяжеляется без фишек типа «The u'unicode' syntax is accepted again for str objects.» Сейчас на что-то до 3.6 лучше не смотреть.

2to3 помогает, но к его советам нужно относиться аккуратно и делать переходный код. Например, `2to3 -f print` надо сопровождать установкой импорта на print_function, то есть все файлы, что он поменял, надо доработать вручную. Автомата на это нет (можно, конечно, написать самому — у нас было немного таких и я не заморачивался).

Наиболее характерные грабли, с которыми столкнулись:

Порядок ключей в переборе словаря. На 2.7 он по умолчанию один и фиксирован по хэшам. На 3.0-3.5 другой и зависит от PYTHONHASHSEED (рандомный, если не указан явно), тоже по хэшам. На >=3.6 — третий, по порядку вставки. Все места, что от него зависели, в итоге перегнали на OrderedDict. После перехода ещё придётся его вычищать.

I/O на сокетах, hashlib, base64 и т.п. — байтовые строки, нужна конверсия.

Проверки типа x == y, x>y, где x целое, y is None, ломаются на Py3.

cmp() убита совсем.

sorted() потребовал явного компаратора.

В Exception и потомках убрали индексацию самого объекта и автоназначение message в случае одного аргумента.

При замене методов доступа словаря типа items -> list(items), iteritems -> items, etc. — надо серьёзно думать над каждым местом, как его реально заменять — требуется ли и допустима ли копия списка? Как реагировать на изменение в процессе итерирования?

Принудительный unicode для os.environ (почему? я так и не понял) и писатели pickle-строк в него (манера странная, но было). В выборе между кодированием в какой-нибудь iso-8859-1 и base64 выбрали последний.

Местами менялись исключения из основного интерпретатора, и мы получали странности — типа у некоторого класса был метод next(), для 3.x он должен был стать __next__(), но это было замаскировано тем, что AttributeError глушилось.

Целая пачка модулей перестала поддерживаться или поменяла реализацию (MySQLdb -> pymysql, smpp -> smpplib, а для JSON-RPC закостылили своё с надеждой при финализации на 3.x уйти опять на стандартное).

Одно из самых тяжёлых: во многих тестах был использован Mock.assert_not_called(), Mock.assert_called().
В 3.5-3.6 эти методы появились и оказалось, что у нас многие такие проверки в тестах были давно сломаны, потому что при переходе с ранних кастомных версий модуля mock на стандартную — были выкинуты эти проверки, и снова добавлены сильно позже. А тупой модуль считал их поэтому целевыми вызовами тестируемого хозяйства, а не проверочными.
В 3.6 наконец сделали проверку типа «assert_* — если не знаем, выкидываем нафиг» — видимо, многие плакались. Но я и сейчас не понимаю, зачем реализацию и управление моком совмещать в одном объекте.

В 2.x CLOEXEC по умолчанию выключен, в >=3.2 — включен, и методы управления разные.

Вместо file() обязательно open(), причём другой состав объектов на выходе и в результате не мокается, как привычно => пришлось писать свой мок.

В общем, продрались. Но местами было грустно.
Only those users with full accounts are able to leave comments. Log in, please.