Прошёл первый месяц занятий в Product Vision Masters. Посвящён он был «категорийному анализу» (внутренняя практика школы, на основе опыта преподавателей) вымышленной вселенной, над которой каждый из участников будет работать. Один участник — одна вселенная, потом обещают объединить нас в команды.
Раз в несколько лет я нахожу время, чтобы покопаться в наработках сообщества по «продвинутым» проверкам типов. Благо у меня под рукой есть взрослый, большой и нетривиальный проект, на котором можно безбоязненно ставить эксперименты.
Не могу сказать что я разделяю оптимизм по поводу продвинутой типизации в Python. Наоборот, считаю, что это как попытка пришить змее ноги — забавно, но вряд ли удобно. Но раз куча людей тратит на это время, надо быть в курсе.
В этот раз я:
Рассказывать буду тезисно, без глубоких обоснований, так как делать нормального качества обоснования для таких холиварных вопросов слишком долго, а я уже дней 5 на копание в этом потратил.
Большая часть поста не про mypy, а про философию проверки типов и будущее Python. Поэтому должно быть интересно, даже если сам mypy вас не интересует.
Эта мысль у меня начала зудеть как-только я выпустил Сказку и начал работать с сообществом её игроков. Но сформулировать её никак не получалось, хотя само явление встречается повсеместно и периодически меня натурально выбешивает.
Вы встречали людей, которые, явно сжульничав и сделав гадость, искренне не понимают в чём проблема, повторяя «я всё сделал по правилам» или «правилами это не запрещено»?
Людей, которые любую работу делают максимально формально, не вникая ни в какие нюансы?
Людей, которые принимают решения строго по «букве закона», даже если «дух закона» этому полностью противоречит?
Так вот, всему этому я придумал диагноз: «травмирование формализмом».
Суть вот в чём…
Меня периодически спрашивают как же мы в «Сказке» договорились о распределении долей потенциальных безумных доходов. Никакого секрета в этом нет, сейчас расскажу.
Тем более, что несмотря на практическое отсутствие денег для делёжки, выработанный подход за 3 года продемонстрировал свою адекватность.
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py
. О них и расскажу, для иллюстрации идеи.