Любопытное исследование вопроса - как побыстрее прочитать много данных из Excel в питоне. Я открыл для себя много нового - например я раньше не слышал про python-calamine и не знал что DuckDb можно использовать для чтения экселя. Идеального универсального решения как обычно не завезли - например, calamine супер-быстрый, но при этом там нет возможности читать построчно итератором - все загружается сразу в память. В общем если вам приходится работать с экселем - рекомендую почитать https://hakibenita.com/fast-excel-python

Ребята, которые сделали ruff, выпустили свой тул для работы с зависимостями для python - uv. Они позиционируют его как замену pip, pip-tools и virtualenv. Написан на расте, поэтому работает быстро.

Также они взяли на себя дальнейшую поддержку rye (который изначально сделал Армин Ронахер, автор flask) и судя по всем планируют постепенно эти проекты объединить в один.

Выглядит вкусно, попробую поиграться с uv на пет-проектах.

Анонс: https://astral.sh/blog/uv
Репозиторий проекта: https://github.com/astral-sh/uv

Легкое чтение на выходные: автор напоминает, что прежде, чем делать pip install klevaya_liba желательно сначала посмотреть, насколько эта либа живая.

В качестве примера приводит Flask-Mail, у которого последний коммит был в 2014 году, но при этом почти полмиллиона скачиваний в месяц.

Это значит, что найденные проблемы в безопасности не исправляются, а совместимость с новой версией питона может отвалиться в любой момент (например, как это случилось с python-kafka и 3.12).

Статья https://freelancefootprints.substack.com/p/abandoned-code-the-hidden-risks-of

Вышел ruff 0.3.0 - которую авторы позиционируют как первую стабильную production-ready версию линтера. Что нового:

- новый style guide, основная идея которого - быть ближе к тому, как форматирует black
- улучшенная поддержка частичного форматирования - когда надо отформатировать не весь файл, а только выделенные строки в ide или только изменённые строки в пре-коммите
- автоматическое форматирование плейсхолдеров внутри f-строк

Подробности в блоге astral https://astral.sh/blog/ruff-v0.3.0

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

И в принципе он не так уж не прав - например кеширования пароля в открытом виде действительно может привести к неожиданным побочкам. Думать, что и как ты кешируешь (да и в целом думать) - полезно, но вот объявлять кеширование в целом security risk-ом — это что-то новенькое 😉

У меня нет доступа к gemini pro, но в целом я готов поверить в такое поведение, пока все что показывал Гугл как минимум "странное" https://new.pythonforengineers.com/blog/so-evidently/

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

Как и в прошлом году, мы встречаемся на Positive Hack Days - 26-го мая мы проведём там Python Day.

Спикеры и гости конференции Python Day будут иметь доступ ко всем техническим трекам на Positive Hack Days в течение всего времени проведения фестиваля.

Планируем целый день докладов и дискуссий про Python. И поэтому мы открываем CFP - ждём ваших заявок на доклады до конца марта.

Мы рассчитываем, что на Python Day придёт порядка 500 профессиональных разработчиков на Python (Middle, Middle+ и Senior) и очень хотим сделать интересную программу для них.

Мы не ограничиваем темы докладов - ожидаем от вас лишь интересных кейсов и знаний в сфере разработки на Python. Время на выступление - порядка 40 минут + 10 минут на вопросы из зала.

ВАЖНО: Чем раньше вы подадите заявку, тем больше времени у ПК будет на её рассмотрение.

Регистрация на само мероприятие откроется чуть позже - следите за новостями.

Заявки на доклады можно подавать тут:
https://docs.google.com/forms/d/e/1FAIpQLSdfWqy2eSlLOcpR6BzHp0ypUqFSBBWrUBgb0ZveD1oKPqOmoQ/viewform

psycopg3 вышла уже почти три года назад, но я уверен, что многие пока по разным причинам сидят на psycopg 2. Вот тут померяли скорость работы psycopg2 vs psycopg3 и результаты на мой взгляд получились неоднозначные:

1. В обычных select from запросах psycopg3 в три раза быстрее psycopg2. Кажется для большинства проектов, у которых чтения больше записи переход вполне оправдан
2. А вот на всяких более редких кейсах типа batch-записи или получения blob-ов из базы тройка проигрывает двойке

В общем я задумался о том, чтобы проекты, где под капотом psycopg начать переводить на третью версию https://www.timescale.com/blog/psycopg2-vs-psycopg3-performance-benchmark/

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

И вот тут мне прямо хорошо зашла тула https://github.com/rohaquinlop/complexipy - это штука для оценки cognitive complexity (можно почитать тут https://habr.com/ru/articles/565652/).

На самом деле есть разные тулы для этого, но complexipy мне понравился скоростью, довольно гибкими настройками и в хорошем смысле замороченностью автора, который пошел за ревью к G. Ann Campbell, которая собственно основной автор методики.
Конечно, у любой методики оценки качества кода есть свои минусы, но чем мне нравится этот конкретный вариант - он хорошо показывает куда смотреть и где скорее всего код требует рефакторинга.

Мы у себя в компании начали аккуратно переходить на новый менеджер пакетов uv (https://github.com/astral-sh/uv) и решил рассказать, как все идет.

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

Все сложности были при использовании нескольких индексов:
- политика разрешения зависимостей uv отличается от pip - это важно, когда используется свой индекс в добавок к pypi
- авторы решили не переиспользовать переменную окружения PIP_EXTRA_INDEX_URL - для uv надо задавать UV_EXTRA_INDEX_URL
- в UV_EXTRA_INDEX_URL лушче прописывать `/simple`-индекс, у меня сначала было не так, pip работал, а uv уже нет

Но какая же uv офигенно быстрая. Вот примеры двух наших разных проектов:

1. Внутренняя библиотека (меньше 20 зависимостей)
- pip-tools 4 минуты 7 секунд
- с uv 10 секунд

2. Большой старый монолит на Django (больше 100 зависимостей):
- с pip-tools 18 минут 19 секунд
- с uv 32 секунды (!!!)

В общем я очень доволен результатом и рекомендую как минимум посмотреть на эту тулзу.

Любопытная статья от Lyft о том, как они полуавтоматически апгрейдят python в 1500+ внутренних репозиториях. Было интересно посмотреть, как они подходят к этому, прямо скажем, непростому вопросу. https://eng.lyft.com/python-upgrade-playbook-1479145d52f4

Я думаю, что многие python-разработчики хотя бы раз в жизни слышали про то, что использование встроенного модуля pickle может быть небезопасным. Но кажется далеко не все знают, в чем заключается "небезопасность". Хорошая статья на lwn, где высокоуровнево разбирается то, как работает pickle и приводятся примеры, как с помощью него вам могут сделать больно.
tl;dr - скачивать веса ml-моделек в pickle-формате - плохая идея. Подробнее тут - https://lwn.net/Articles/964392/

Frost Ming, автор менеджера пакетов pdm выложил несколько постов про его внутреннее устройство:

- для чего нужен lock-файл, как он устроен у pdm и почему именно так https://frostming.com/en/2024/pdm-lockfile/
- как pdm разрешает зависимости и какие есть стратегии формирования lock-файла https://frostming.com/en/2024/pdm-lock-strategy/

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

P.S. Автор честно предупреждает, что обе статьи — это автоматический перевод с китайского, но тем не менее читается легко и понятно.

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

встречайте: https://www.youtube.com/@sobolevn

уникальность формата в том, что я рассматриваю одну узкую тему с трех уровней сложности: junior, middle, senior. так что, контент должен быть интересным для всех уровней Python разработчиков!

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

важные ссылки:
- все материалы курса: https://github.com/sobolevn/the-best-python-course
- мой гитхаб: https://github.com/sobolevn
- поддержать мою работу: https://boosty.to/sobolevn
- вступить в наше новое глобальное сообщество: https://discord.python.ru

пишите в комментах к видео, если узнали что-то новое!
мета информация: https://www.youtube.com/watch?v=SVBPkrs9UFg
первый выпуск: https://www.youtube.com/watch?v=WBKf2Cw_9Pc

буду рад обратной связи!
в ближайших планах:
- починить звук и свет
- избавиться от слова "интересный" в описании примерно всего
- сделать много новых видео по разным темам

Я всегда был сторонником обучения на практических задачах и сам не люблю при изучении новых языков/фреймворков/библиотек решать синтетические задачки. Поэтому мне понравился подход ребят из https://codecrafters.io/ - "напишите Redis, Git или Docker своими руками". Я некоторое время мариновал этот сайт в закладках, но тут во время отпуска решил попробовать.

Как это работает:
- Они разбивают большой проект на небольшие задачки по принципу "давай запустим сервис на порту", "теперь давай напишем простой ping/pong" и так далее
- Каждую небольшую задачку ты коммитишь, и они прогоняют по ней автоматические тесты - если тесты зеленые, то ты молодец 🙂
- Там есть очень базовые объяснения как что работает - типа туториалов "как устроен tcp" или "как работает пакет net в go", но их явно недостаточно, чтобы выполнить задание
- Самое интересное — это возможность посмотреть чужой код, прошедший тесты на каждом шаге - они просто показывают тебе покрашенные дифы и по ним можно разобраться, как именно человек переписал код чтобы решить эту задачу

У меня не было много времени, чтобы с этой штукой поиграться, но я написал базовый redis на python (который я знаю хорошо) и go (который я знаю так себе) и вот какие выводы сделал:
- Мне подход показался очень интересным, я точно буду дальше пользоваться. Пока я не платил им денег, но кажется даже без денег на тех бесплатных проектах, что у них есть, можно себя занять на некоторое время
- Это хорошая игрушка для мидлов и выше. Возможно упорный джуниор сможет разобраться, но в этом случае должен очень классно быть прокачан скилл "у меня ничего не работает, но я буду разбираться до победного"
- Мне очень понравилась фича просмотра чужих диффов - особенно для go, с которым я знаком поверхностно - мне было очень интересно посмотреть на разные подходы к решению одной и той-же задачи и что-то утащить себе в копилочку
- Важно не копировать код у других. Я для себя нашел такой вариант - там, где я разбираюсь (python) - пишу сам и смотрю чужие интересные находки. Там, где я разбираюсь не очень (go) - компилирую свой вариант из разных вариантов переписывая под свое чувство прекрасного

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