Библиотека питониста

🧠 Почему потоки в Python не всегда ускоряют код

Частая мысль:

«Добавлю threading → станет быстрее»

На практике — не факт.

В чём причина

В классическом Python есть GIL — он не даёт нескольким потокам выполнять код одновременно.

Поэтому:
✔️ I/O (API, файлы) → быстрее
✔️ CPU (вычисления) → почти нет

С появлением PEP 703 Python постепенно уходит от GIL. Теперь потоки могут работать параллельно.

Где всё ломается:

counter += 1

На деле это: read → compute → write

В потоках это приводит к race condition:

import threading

counter = 0

def worker():
    global counter
    for _ in range(1_000_000):
        counter += 1

threads = [threading.Thread(target=worker) for _ in range(8)]

for t in threads: t.start()
for t in threads: t.join()

print(counter)  # ≠ 8_000_000

«Фикс», который замедляет:

lock = threading.Lock()

with lock:
    counter += 1

Работает правильно, но: потоки стоят в очереди → параллельности нет

Как правильно:

from concurrent.futures import ThreadPoolExecutor

def worker():
    local = 0
    for _ in range(1_000_000):
        local += 1
    return local

with ThreadPoolExecutor(max_workers=8) as ex:
    result = sum(ex.map(lambda _: worker(), range(8)))

print(result)  # 8_000_000

💡 Главное правило

Потоки не должны делить данные во время работы: делят → медленно, независимы → быстро

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

🐍 Django: 20 лет на арене. Почему мы всё еще верим в мифы о «старичке»?

Django исполнилось 20 лет — для технологий это солидный возраст.

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

Вот некоторые мифы:

1. «Django находится в режиме поддержки (maintenance mode)»

Многие думают, что в Django только исправляют баги.
Реальность: Новая фича вливается в проект в среднем каждые 5,5 дней, а релизы с новыми функциями выходят каждые 8 месяцев.
Почему возник миф: Из-за политики строгой стабильности и обратной совместимости старый код продолжает работать годами, что создает иллюзию отсутствия изменений.

2. «Django — это медленно»

Сравнения с Fast API в бенчмарках часто показывают Django не в лучшем свете.
Реальность: Бенчмарки часто сравнивают «яблоки с апельсинами». Django по умолчанию включает в себя промежуточное ПО (middleware) для безопасности и удобства, в то время как в микрофреймворках это нужно добавлять вручную.
Инсайт: В реальных приложениях узким местом почти всегда является база данных, а не сам фреймворк. При правильной настройке индексов и запросов Django показывает отличную производительность.

3. «Django не подходит для API»

На официальном сайте всё еще нет документации по созданию API, а туториалы учат рендерить HTML-шаблоны.
Реальность: Более 50% сообщества используют Django именно для создания API, применяя Django Rest Framework (DRF) или Django Ninja.
Экосистема: Вокруг фреймворка существует живая и растущая среда библиотек для работы с API, просто об этом мало говорят на официальных ресурсах.

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

🚀 pip 26.1: lock-файлы и “cooldown” зависимостей

Вышел pip 26.1, и это один из самых интересных апдейтов за последнее время.

Главное изменение — pip начинает двигаться в сторону детерминированных зависимостей и безопасности.

Теперь pip экспериментально поддерживает lock-файлы:

pip install -r pylock.toml

Это означает:
— фиксированные версии зависимостей
— воспроизводимые окружения
— меньше сюрпризов при деплое

По сути, pip догоняет то, что уже давно есть в poetry, uv и других инструментах.

🧊 Dependency cooldowns

Очень интересная идея:

--uploaded-prior-to P7D

Позволяет не устанавливать свежие пакеты, загруженные, например, за последние 7 дней.

Зачем это нужно:
— защита от supply chain атак
— время на обнаружение вредоносных пакетов
— снижение риска “нулевого дня”

Фактически — простой способ добавить слой безопасности без сложной инфраструктуры.

Что ещё улучшили:
— лучшее разрешение зависимостей (быстрее и стабильнее)
— улучшена работа с hash’ами и constraints
— оптимизация памяти
— фиксы багов и security issues

🔗 Ссылка на блог-пост

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

Логирование в Python в 2026: что реально использовать

Если вы всё ещё думаете, что логирование — это просто print(), пора обновить картину.

Сегодня в Python есть три основных подхода, и каждый решает свою задачу:

1. Стандартный `logging`
База всей экосистемы. Через него логируют Django, FastAPI и почти все библиотеки.
Подходит, если вам нужна стабильность, интеграции и контроль.
Минус — многословная настройка и «олдскульный» API.

2. structlog
Лучший выбор для продакшена и микросервисов.
Логи — это словари → легко превращаются в JSON → удобно для аналитики и observability.
Плюс: нормальная работа с контекстом (request_id, user_id) через contextvars.

3. Loguru
Когда хочется просто и быстро.
Импортировали logger — и уже логируете.
Отлично подходит для небольших сервисов, скриптов и MVP.

🔗 Полный обзор: https://clc.to/fxbIEA

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

🔥 4 привычки кодеров

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

но, я собрал 4 привычки адептов «чистого кода», (которые обычно все практикуют) 🤡

• Бесконечный рефакторинг рабочего кода.
Кажется, что так ты делаешь продукт лучше. Итог: жестко падаешь в перфекционизм. Переписываешь функцию по три раза, а бизнес ждет релиз. Закрываешь вкладку и в голове абсолютная пустота, время потрачено, а новых фичей ноль.

• Упарывание в сложную архитектуру
Сеньоры на ютубе обещают золотые горы, если внедрить микросервисы куда угодно. Итог: получаешь красивый overengineering-проект для мамы и 0 запущенных продуктов в срок, пока конкуренты клепают MVP на коленке.

• Душные споры на ревью
Неплохо, но как итог: ты пишешь полотна текста и тратишь часы на поиск глупой придирки к стилю, потому что банально фокус сместился с реальной задачи на эго.

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

Проблема в том, что ни один из этих путей не дает самого главного - скорости и проверки гипотез. Реальному рынку плевать на твой идеальный код за 3 дня. Бизнес предпочтет код от ИИ-агента за 5 минут, который уже завтра начнет приносить деньги.

Хочешь обкатанный на нас лично и 100х учениках метод, как перестать кодить руками и начать делегировать задачи автономным системам?

👉 Заходи сюда, но у нас осталось всего 4 места, набор идет до завтрашнего дня.

P. S. Если интересно еще что-нибудь почитать от меня, то заходите в «Азбуку Айтишника», там я рассказываю об айти-базе, также у меня там есть бесплатный гайд на 15 глав по ии-агентам

Библиотека питониста

#развлекалово

🐍 В Python 3.15 появятся sentinel values (PEP 661)

После ~5 лет обсуждений в Python добавляют простую, но очень полезную вещь — sentinel-значения.

Иногда важно отличать:
— аргумент вообще не передали
— передали None
— передали конкретное значение

Раньше это делали через костыли (типа `object()`), теперь — нативно.

👉 Пример:

MISSING = sentinel("MISSING")

class Logger:
    def __init__(self, level: MISSING | None | str = MISSING):
        if level is MISSING:
            self.level = get_global_default_level()
        elif level is None:
            self.level = None  # отключить логирование
        else:
            self.level = level

Что это даёт:
— можно чётко понять: аргумент не передан или передан None
— чище API
— меньше неочевидных багов

По сути, теперь у функции есть 3 состояния:
1. не передали → взять дефолт
2. передали None → особая логика
3. передали значение → использовать его

⚡️ Это мелкое изменение, но оно сильно упрощает дизайн функций и библиотек.

Использовали ли вы подобные паттерны раньше или обходились None?

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

🗓️ Уже через пару часов стартует вебинар!

Тема:

Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены

Ждем вас сегодня в 19:00 по московскому времени. Не пропустите начало, будет много практики!

👉 Успей занять место

🐍 Python tip: как писать чище — `enumerate()` + распаковка

Иногда в цикле вам нужно сразу две вещи:
номер элемента и значения внутри него.

Вместо лишнего кода это можно сделать в одну строку:

for index, (service, status) in enumerate(services, start=1):

Что здесь происходит:
enumerate() даёт вам индекс,
а (service, status) сразу распаковывает кортеж.

Код получается заметно чище:
не нужно заводить отдельный счётчик,
не нужно писать item[0], item[1],
и в целом легче читать, что происходит.

Особенно полезно, если работаете с:
— API-ответами
— списками кортежей
— логами / мониторингом

📌 По сути, это маленький приём, который сильно улучшает читаемость.

А вы как обычно пишете такие циклы — через распаковку или по индексам?

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

📚 В Read the Docs теперь нативно поддерживается uv Python package manager

Небольшая, но очень приятная новость для тех, кто собирает документацию.

Теперь uv можно использовать прямо в .readthedocs.yaml — без костылей и кастомных шагов установки.

💡 Что это даёт
— быстрее установка зависимостей
— чище конфигурация
— нормальная поддержка pyproject.toml и uv.lock

Если используете современный стек:

python:
  install:
    - method: uv
      command: sync
      groups:
        - docs

Если остались на requirements.txt:

python:
  install:
    - method: uv
      command: pip
      requirements: docs/requirements.txt

💬 Если у вас документация ещё на pip — возможно, это тот самый момент попробовать перейти.

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст