Python Hypothesis

Давно хотел посмотреть на hypothesis — генератор фикстур для тестов. Сделал это пока в очередной раз колупал типы в Python.

Hypothesis позволяет описывать генераторы входных данных для тестов и запускать тесты сразу на всех сочетаниях данных. В случае ошибки библиотека попробует локализовать её в наиболее простом наборе данных, чтобы было проще понять проблему и воспроизвести ей. Генераторы для базовых типов идут в комплекте, поэтому деление на ноль она ловит хорошо :-)

Если кратко, то мне понравилось, рекомендую, буду использовать, но не всегда. Подробнее под катом.

Далее

Yet another Тарантога

Не только я пытаюсь собрать всю свою информацию в одном месте.

Вот описание созданной за год инфраструктуры от другого энтузиаста.

Знакомство с блогом karlicoss и подтолкнуло меня делать собственный велосипед. Всегда приятно узнать, что ты не один такой упоротый :-) Там же я позаимствовал пару базовых концепций.

В отличии от меня, karlicoss избрал более прагматичный подход:

• Поставил во главу угла data liberation — освобождение данных — получение копий всех сущенственных данных, которыми пытаются владеть облака и прочие сервисы. Возможно, логика в том, что владение данными первично, а как их обработать всегда можно придумать.
• Не пытается (пока) изобретать универсальные форматы или универсальный софт. Просто делает инфраструктуру экспорта, хранения и обработки информации, которая работает. То есть у него получается сеть из источников, экспортёров, обработчиков и дашбордов.

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

Но из того, что чего-то не вижу, не следует, что этого нет.

Я и «умный» GUI в IDE

Updated: Этот пост написан до появления Copilot. Моё мнение о Copilot в отдельном посте.

В комментарии к модной типизации в Python мне обоснованно указали, что я не рассмотрел использование типов для помощи IDE. В частности, для автодополнения и подсказок.

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

Собственно году в 2010 я отказался от «умных» версий того же автодополнения и не жалею. В то же время, мои периодические порывы сменить Emacs на крутую современную IDE во многом вызваны как раз желанием проверить, не сделали ли наконец нормальный программистский CAD с действительно крутыми помощниками. Пока не сделали, так что сижу на Emacs :-)

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

На сколько я знаю, моя позиция не распространена, поэтому расскажу про её логику подробнее.

Далее

Минидрама: Python, C, Rust, криптография и Gentoo

Новость с деталями.

1. Часть кода популярной Python криптобиблиотеки переписали на Rust.
2. Сломалось CI у кучи людей.
3. Дополнительно сломалось чегой-то в пакетном менеджере Gentoo.
4. Изменения незаметили, так как… ну кто следит за криптолибами? Их просто ставят.
5. Все думали, что cryptography следует semantic versioning, оказалось, что нет :-D

В итоге:

• Разработчики сказали, что откатывать Rust взад не будут — это более кошерный язык для криптографии, чем C.
• Gentoo оказалась не так уж и поломана — зависимость оказалась ненужной, но осадочек остался.
• Люди с CI поплакали, но донастроили что надо было донастроить, и вернулись к своим делам.

Соль драмы в том, Gentoo поддерживает часть архитектур, которые не умеют в Rust. Одновременно Gentoo сильно зависит от Python. В этот раз пуля пролетела мимо, но возникли опасения, что Rust будет всё активнее использоваться к инфраструктуре Python. и в какой-то момент станет необходимой зависимостью. Что в этом случае случится с поддержкой минорных архитектур не ясно.

Далее

Google стал Visionary Sponsor для Python

Новость в блоге PSF.

Не знаю что в PSF понимают под Visionary, но ничего хорошего такое визионерство языку не несёт. Конечно, если оно вообще что-то несёт. Но не вижу смысла продавливать отдельный термин для простого спонсорства — вряд ли PSF сама выбрала такую формулировку.

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

Своим текущим состоянием: идеологией, возможностями, распространённостью Python обязан в первую очередь рядовым пользователям, не Google.

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

Далее