Заметки о контейнеризации
Не о всей конечно, о кусочке.
Забавно, но я за карьеру мало взаимодействовал с контейнерами. Максимум — писал код, который в них работал. Контейнеры либо особо не требовались, либо готовились другими людьми.
В конце прошлого года решил обновить инфраструктуру Сказки, заодно посмотреть чего да как с контейнерами. Взял Docker, как самую популярную штуку.
Модная типизация в Python
Разработчики пришивают типы к Python.
Раз в несколько лет я нахожу время, чтобы покопаться в наработках сообщества по «продвинутым» проверкам типов. Благо у меня под рукой есть взрослый, большой и нетривиальный проект, на котором можно безбоязненно ставить эксперименты.
Не могу сказать что я разделяю оптимизм по поводу продвинутой типизации в Python. Наоборот, считаю, что это как попытка пришить змее ноги — забавно, но вряд ли удобно. Но раз куча людей тратит на это время, надо быть в курсе.
В этот раз я:
- Посмотрел что из себя представляет mypy и чем может быть полезно (мало чем).
- Посмотрел чем можно автоматически сгенерировать аннотации типов (ничего рабочего нет).
- Подумал о том, как правильно использовать проверку типов в Python, раз их так форсят.
- Нашёл библиотеку, реализующую идеологически верный подход.
Рассказывать буду тезисно, без глубоких обоснований, так как делать нормального качества обоснования для таких холиварных вопросов слишком долго, а я уже дней 5 на копание в этом потратил.
Большая часть поста не про mypy, а про философию проверки типов и будущее Python. Поэтому должно быть интересно, даже если сам mypy вас не интересует.
Генерация текста на русском по шаблонам
И пять лет не прошло (на самом деле прошло), как у меня дошли руки рассказать чем генерируются тексты в Сказке (хабр).
Стастья о python библиотеке для генерации текстов с учётом зависимости слов и их грамматических особенностей.
Github: https://github.com/the-tale/utg PyPi: https://pypi.org/project/UTG/
Тестирование семантики кода
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py . О них и расскажу, для иллюстрации идеи.