Как вручную разрешить ленивый импорт в Python

У объекта, созданного через lazy import json, есть метод resolve(). Его можно обнаружить с помощью dir(globals()["json"]), а справка поясняет: метод разрешает ленивый импорт и возвращает настоящий объект модуля.

Вызов globals()["json"].resolve() возвращает модуль json, но имя в глобальном пространстве по-прежнему указывает на объект lazy_import. Автор предполагает, что при автоматическом разрешении Python вызывает тот же метод, а затем присваивает имени полученный модуль.

В этот раз «явное лучше неявного» можно понимать буквально. В разборе показано, как исследовать этот механизм через dir() и help(); открытым остаётся вопрос, что именно запускает автоматическое разрешение импорта.

Почему str.splitlines() видит больше переносов, чем чтение файла

У Python два разных понятия границы строки. Универсальный режим чтения файла распознаёт LF, CR и CR LF. str.splitlines() шире: десять отдельных кодовых точек плюс CR LF.

Туда входят вертикальная табуляция, перевод страницы, разделители строки и абзаца Unicode и три ASCII-разделителя данных. Python собрал этот набор из правил ASCII, Unicode-переносов и двунаправленного текста. За простым методом стоят несколько наборов символов и пять документов Unicode.

История всех разделителей полезна при обработке внешнего текста: символ, задуманный как граница записи, может стать границей строки. Поэтому сначала сверяйте формат входа, а потом выбирайте чтение файла или splitlines().

Как собирать динамические фильтры Django через Q-объекты

Q() представляет условие для SQL-запроса. Такие объекты можно объединять операторами & и |, отрицать через ~ и передавать в один вызов filter(). Это позволяет явно задать, какие условия должны выполняться вместе, а какие служат альтернативами.

В примерах с Q-объектами поисковая строка разбивается на слова, для каждого строится проверка icontains, а затем условия соединяются через OR. Для небольших наборов данных этого достаточно, но на больших SQL-запросы с OR могут работать медленно.

Фильтры можно вынести в функции или методы моделей и собирать из пользовательских параметров. Автор предпочитает один filter(): так вся логика запроса видна в одном месте и проще контролировать JOIN при обходе связей. Явное условие лучше неявной цепочки, почти по PEP 20.

Как заменить цепочку isinstance на singledispatch

Когда обработка типов разрастается, цепочка isinstance() превращает одну функцию в дерево условий. Декоратор functools.singledispatch оставляет единый интерфейс, а реализации для отдельных типов регистрируются независимо. Выбор происходит по типу первого аргумента.

Учитывается и наследование: регистрация для Mapping подходит обычному dict через порядок разрешения методов. Обратная сторона той же механики: bool наследуется от int, поэтому для иной семантики ему нужен отдельный обработчик.

Аннотация помогает register() определить тип, но list[str] и list[int] не становятся разными случаями во время выполнения. В разборе singledispatch также показано, как тестировать обработчики отдельно, проверять выбор через dispatch() и проектировать явный fallback.

Как разделить синхронный и асинхронный Python-клиенты

При переписывании akismet автор отказался от одного класса с обычными и асинхронными методами. Клиент проверяет ключ API при создании, а для этого нужен HTTP-запрос. Синхронный запрос заблокировал бы асинхронный код, а запуск проверки через async потребовал бы заранее выбрать и получить работающий цикл событий.

Решением стали отдельные SyncClient и AsyncClient. Заодно новые имена позволили оставить прежний класс Akismet устаревшим, но рабочим, чтобы пользователи могли перейти без немедленной поломки API. Названия скучные, зато состояние клиента и способ ввода-вывода больше не приходится угадывать.

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

Как запускать собственный SQL через миграции Django

У models.Index нашлось необычное применение: его подкласс можно добавить в Meta.indexes, чтобы Django включил объект в автоматически созданную миграцию. При её выполнении фреймворк получит SQL из методов create_sql и remove_sql. Так к схеме таблицы можно привязать, например, комментарии или триггеры.

В django-security-label этот механизм задаёт правила анонимизации PostgreSQL прямо рядом с полями модели. Когда модель меняется, система миграций добавляет или удаляет соответствующие метки в схеме. Получается явно и рядом с предметной моделью, хотя автор прямо называет приём хаком.

Разбор механизма и пример с анонимизацией помогут оценить границы подхода. SQL из упрощённого примера копировать нельзя: он не экранирован должным образом.

Как проверять инварианты Python-кода с Hypothesis

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

С @given и стратегиями можно проверять идемпотентность, сериализацию с обратным преобразованием и ограничения коллекций. Если свойство нарушено, Hypothesis упрощает вход до минимального контрпримера: вместо строки на тысячи символов остаётся значение, на котором удобно отлаживать код.

Практический разбор Hypothesis показывает стратегии генерации и интеграцию с pytest. Такие проверки дополняют обычные тесты, а найденную регрессию лучше закрепить отдельным тестом или @example.

Как коллизии превращают построение set в Python в квадратичную задачу

Привычное O(1) для set и dict предполагает, что коллизии редки. Если много ключей получают одинаковый хеш, интерпретатору приходится искать свободные ячейки и перебирать кандидатов при проверке вхождения. O(1) здесь полезная модель, а не договор с интерпретатором.

В эксперименте с подобранными целыми числами удвоение размера почти учетверяло время: построение множества из 16 000 элементов заняло 1072 мс, а из 100 000 — 45 секунд. Проверка всех элементов росла так же.

Отдельно автор измерил влияние процессорного кеша: поиск случайных строк в dict замедлялся по мере роста таблицы даже без коллизий. Это другой механизм, поэтому при неожиданной деградации стоит отдельно проверять распределение хешей и размер данных.

partial или lambda: как специализировать колбэк без сюрпризов

functools.partial заранее связывает часть аргументов и возвращает вызываемый объект. Сохранённые именованные аргументы работают как значения по умолчанию: при вызове их можно переопределить. Проверки новой сигнатуры при этом нет, поэтому повторная передача одного параметра закончится TypeError.

Разница с lambda проявляется во времени связывания. Лямбда получает текущее значение имени при выполнении, а partial сохраняет переданный объект при создании. Но копии не делает: изменения связанного списка будут видны, а долгоживущий колбэк удержит контекст в памяти.

Сравнение двух способов специализации функций сводится к питоничному правилу: если нужно только связать аргументы, подходит partial. Если адаптер проверяет данные, логирует или преобразует аргументы, яснее написать именованную функцию через def.

Как OpenBLAS ускоряет NumPy в браузере

Раньше браузерная сборка NumPy выполняла np.matmul обычными циклами на C, которые не учитывали кэш процессора и векторные инструкции. Теперь NumPy 2.5.3 из Emscripten-forge по умолчанию подключает OpenBLAS 0.3.34 для WebAssembly. На квадратных матрицах 1024 × 1024 умножение ускорилось примерно в 30,92 раза для float32 и в 14,90 раза для float64.

Прирост зависит от операции. Функции np.linalg ускорились слабее, поскольку реализация LAPACK ещё не оптимизирована специально для WebAssembly. Экспериментальная OpenBLAS 0.3.35 добавляет новые векторные ядра, а сборка с Relaxed SIMD даёт дополнительное ускорение только в браузерах с поддержкой этого расширения.

Бенчмарки и настройки стенда помогают сравнивать сборки по размеру матриц, типу данных и браузеру, а не переносить одну красивую цифру на весь NumPy.

Как проверять плагины через контракт Pydantic и FastAPI

Сервис может отвечать по нужным адресам и всё же возвращать несовместимые данные. В схеме общего API-контракта модели Pydantic для /ready, /catalog и /encode/ вынесены в отдельный пакет.

Плагин использует эти модели в обработчиках FastAPI, а платформа проверяет ими ответы при регистрации. Если структура не совпадает, сервис не подключается.

Контракт фиксирует и ответственность: разбиением входных данных управляет плагин, а проверки доступа вынесены в зависимости FastAPI. Это ловит несовместимый формат до подключения, но не проверяет правильность вычислений.

Как битовые множества сокращают память моделей Pydantic

Explicit is better than implicit, но хранить набор явно переданных полей в полноценном Python set оказалось накладно. Memray показал: создание model_fields_set заняло почти 800 МБ на миллионе экземпляров модели с семью полями.

Поскольку поля модели упорядочены, каждому можно назначить номер бита: 1 означает, что значение передали при создании, 0 — что использовано значение по умолчанию. Имена дополнительных полей, которых нет в схеме, остаются в отдельном set.

В разборе реализации показано, как выбирать u8, u16 или вектор для моделей разного размера. На тесте с небольшими значениями замена сократила память на 55%. Полезный пример того, почему профилировать стоит не только __dict__, но и служебные структуры каждого экземпляра.