Пользователь Reddit поделился Python-библиотекой для быстрых запросов к файловой системе и выполнения действий над найденными файлами.

Основная идея: вместо кучи строк кода, os.stat и datetime писать так:

query = Query(
    where_expr=(AgeDays() > 7) & (Size() > "10 mb") & Suffix(".log"),
    from_paths="C:/logs",
    threaded=True
)
result_set = query.select()

Т.е. найти логи старше 7 дней и больше 10 МБ.

Выглядит удобно, но как-то не очень pythonic, вам не кажется? Как будто если делаешь что-то SQL-like, то лучше напрямую SQL и взять, а не изобретать мини-язык внутри Python. И это как раз самое интересное — в комментах начали предлагать как можно сделать лучше.

Например, вот так:

query(lambda p: p.age_days < 7 and p.size > 10_000_000 and p.suffix == ".log")

Добавить обёртку, которая будет вычислять необходимые свойства по запросу с использованием cached_property и получим по сути то же самое, но проще.

Или использовать модуль ast и такой синтаксис:

query("age_days < 7 and size > 10_000_000 and suffix == '.log'")

А может вообще что-то lisp-подобное:

query(("and", ("age_days", ">", 7),
              ("size", ">", 10_000_000),
              ("suffix", "==", ".log")))

Или добавить callable-объекты, которые можно передавать в фильтры, получится куда более нативно:

dir = pathlib.Path('/var')
for file in filter(OlderThan(days=7) & LargerThan(MB=10),dir.rglob("*")):
    print(file.as_posix())

Лично мне, админу канала @zen_of_python, последний вариант кажется самым удобным. Не самый привычный синтаксис, но читается однозначно. И возможность задавать время и размер файлов в привычных единицах — тоже плюс.

Если для ускорения добавить конкурентность и кэширование, как сделал автор исходной библиотеки, то получится прекрасный инструмент.

А какой стиль вам больше понравился? Как бы вы реализовали?

Какую версию Python взять, чтобы всё работало без лишних проблем?

С одной стороны, хочется более свежую: в 3.14 завезли free-threading и вообще много чего улучшили по производительности. Но не все библиотеки ещё подтянулись. Например, Numba ещё 3.14 не поддерживает.

Хороший совет — вооружитесь uv и последовательно пробуйте все версии начиная с самой свежей. Первая, которая заработает, и будет вашей. По сути самая свежая из тех, которую поддерживают все зависимости у вас в проекте.

Также полезно посмотреть на релизный цикл (на картинке к посту). Очевидно не стоит брать версии, которые уже не поддерживаются. Спускаться ниже 3.10 будет не самым безопасным вариантом. Ровно как и пробовать то, что ещё не выпущено официально — на 3.15 заглядываться рановато.

По состоянию на ноябрь 2025 версия 3.13 выглядит хорошей золотой серединой. Почти все уже успели добавить поддержку, а от ведущей 3.14 отставание всего на один шаг.

А какие версии вы используете у себя в проектах?

#обсуждение
@zen_of_python

Свежий пет-проект от (видимо) скучающего на досуге питониста — терминальный Git‑клиент на чистом Python, вдохновлённый LazyGit; ставится через pip и работает без внешнего git CLI. Попробовать: pip install pygitzen.

Что даёт: навигация по коммитам, просмотр diff, панель статусов файлов в стиле VSCode, ветко‑зависимая история и индикаторы «пушнуто/локально» без вызова системного git.​

Зачем: когда в окружении нельзя ставить ничего кроме Python‑пакетов, нужен «чисто Python» инструмент для Git с удобной навигацией и минимумом интеграций.​

Автор просит фидбек по недостающим функциям и удобству UI, так что можете отписаться в репозитории. Вам плюсик в карму, автор порадуется.

Проект, послуживший вдохновением: https://github.com/jesseduffield/lazygit

Ну и, конечно, кто-то написал аналог на Rust, чтобы было ультра-быстро, а скорее просто потому что может: https://github.com/gitui-org/gitui

Как вам такие поделки? Как минимум романтично же, консольные клиенты как будто пахнут старыми добрыми временами, вы не находите?

@zen_of_python

Как провести проверку типов в 1,8 миллионах строчек Python-кода за секунду? Нил Митчел рассказывает как новый тайп-чекер Pyrefly достигает такой скорости (дубляж на русский).

Аннотации типов появились ещё в 2014 году и с тех пор стали значительно сложнее: дженерики, подтипы, flow types, field refinement и другие не всем даже известные слова. Pyrefly моделирует и проверяет эту сложную систему и делает это быстро.

В принципе тем же самым занимается uv ty, но у ребят из Astral немного другой подход: дать пользу программисту аккуратно, не ошибиться случайно в коде, который хоть и без типов, но теоретически может быть валидным. Можно сказать, что Pyrefly более агрессивный и стабильный, хотя оба проекта ещё в альфе.

Попробовать можно прям на сайте проекта: pyrefly.org/sandbox

Что ж, наконец-то кто-то сможет угнаться за скоростью написания вайб-кода и проверить хотя бы типы.

@zen_of_python

Совет управляющих Python одобрил два PEP — 798 про распаковку в comprehensions и 810 про явные ленивые импорты, оба целятся в Python 3.15.

PEP 798 добавляет возможность применять распаковку прямо в comprehensions и генераторах: можно использовать символы звездочки для объединения и слияния, например [*it for it in its] или {**d for d in dicts}. Приняли с оговоркой: и синхронные, и асинхронные генераторные выражения должны использовать явные циклы, без yield from, чтобы сохранить простой и единый стиль, ближе к поведению itertools.chain.from_iterable.

PEP 810 вводит явный синтаксис ленивых импортов: lazy import json и lazy from json import dumps, когда модуль реально загрузится только при первом обращении к имени — полезно для ускорения старта и экономии памяти. Совет уточнил детали: .pth не поддерживают ленивые импорты, появится sys.get_lazy_imports(), и будет зафиксирован приоритет между переменной окружения, флагом -X и вызовами sys.set_lazy_imports(), при этом стилистические правила сортировки оставят линтерам и форматтерам.

P.S. Кто такие эти ваши «совет управляющих»? После ухода Гвидо с роли BDFL в 2018 сообщество приняло модель управления PEP 8016 — стратегию языка и финальные решения по PEP принимает избираемый из core-разработчиков Совет из пяти человек. Этот Совет переизбирается после каждого мажорного релиза голосованием среди core-dev’ов и выступает финальным арбитром по спорным вопросам развития языка.