Почему мы отказались от выражения «assert» в Python

Похоже вы так и не разобрались для чего нужен assert.

Он нужен в первую очередь для "sanity checks": проверять то, что в продакшн системе валидировать не нужно (так как не имеет смысла или слишком дорого). Каждый упавший assert должен означать ошибку в вашем коде. Если вы допускаете, что в системе при каких-то обстоятельствах выражение в assert будет ложным, то в этом месте вам assert не подоходит - там должна быть полноценная валидация.

PS: В целом очень странно начинать статью с заведомо неправильного определения этого ключевого слова. 90% проблем и вопросов отпадает, если сразу написать правильное определение.

эмм... а зачем вы его использовали в продакшене, если в доке буквально написано: "assert предназначен для отладки"
https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement

Концептуально, ассерты это больше документация, нежели код.

Да, она выполняется в режиме отладки для удобства, но это вторично. Их отключают в сборках для продакшен, чтобы не снижать перфоманс.

Общее правило: assert не должны ни каким образом влиять на логику выполнения программы (как встроенная документация или логирование, например). Поведение программы с включенными ассертами должно быть точно таким же как и с выключенными.

Если нужна проверка, которая должна менять поток исполнения программы: валидация входных и выходных данных, проверка ошибок времени исполнения, и т.п - то нужно использовать другие выразительные средства языка (такие как if, raise, да хоть монады %). Но не assert.

В питоне подложили свинью: по умолчанию __debug__ включен и AssertionError наследуется от Exception. В результате они бросаются и перехватываются наряду с другими исключениями времени исполнения. Это дало соблазн горячим головам применять их в качестве API для управления логикой программы: в валидаторах, юнит тестах и т.п. Дичь, но от pytest уже ни куда не деться.

В общем, если использовать assert по делу, то ни чего плохого в них нет. Но в питоне, порой, здесь приходится бороться с когнитивным диссонансом.

Собственно, все вопросы к авторам Pydantic. У них же должна быть веская причина игнорировать официальную документацию.

Все остальные указанные случаи - только указывают на смысл assert - отладка кода.

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

А зачем кому-то запускать тесты с pytest с оптимизациями? Это же скорее всего юнит-тесты, упал-отладил. А для всего прочего со сложного логикой pytest.fail().

Суть assert, как уже подмечено выше, именно в проверке только внутренних инвариантов программы и тестах. И то, что в pydantic его затащили для проверок данных - это косяк проектирования и не верное использование инструмента.

Использование и применение очень похожи на то, как это реализовано в Java: использование-assert

Это косяк авторов pydantic, а не дизайн. По идее им можно отправить баг репорт.

Ни в C/C++, ни в Python, ни в Java assert не предназначены для проверки чего-то в продакшене, это официально указано в документации и опция релизного режима их тихо и незаметно отключает.