⭐ Python без GIL: эпоха настоящего многопоточного исполнения

GIL — удобное решение для безопасности, но стало тормозом.
— Guido van Rossum

✳️ Что такое GIL

GIL (Global Interpreter Lock) — глобальная блокировка интерпретатора Python. Она не даёт выполнять Python-байткод более чем одному потоку одновременно.

Это решение появилось ещё в 90-х, когда одноядерные процессоры были нормой. Сейчас же — реальность многопоточная. А GIL мешает полностью использовать многозадачность на уровне CPU.

✳️ Почему GIL — проблема

Из-за GIL Python-программы не могут полноценно использовать многопоточность в CPU-bound задачах. Вместо этого:
— мы используем multiprocessing, создавая отдельные процессы (дорого)
— мы прибегаем к C-библиотекам: NumPy, Cython, PyTorch, чтобы обойти ограничения

Но всё это — костыли. И комьюнити давно мечтает избавиться от GIL.

✳️ PEP 703: решение пришло

PEP 703 предлагает сделать GIL опциональным.

Вместо полного отказа от GIL — аккуратный переход:

1. Python 3.13 (вышел в 2024) — можно собрать без GIL (--disable-gil)
2. 2026–2027 — возможность переключения GIL в рантайме
3. 2028+ — по умолчанию Python будет без GIL

✳️ Как попробовать Python без GIL прямо сейчас (Mac)

1. Скачайте установщик Python 3.13 с офсайта
2. На этапе установки выберите Free-threaded Python (experimental)
3. После установки появятся два интерпретатора:
— python3.13 — обычный
— python3.13t — Python без GIL

Проверьте:

import sysconfig
print(sysconfig.get_config_var("Py_GIL_DISABLED"))
# True для python3.13t

✳️ Проверка в бою: ускорится ли код

Пример CPU-bound задачи с потоками:

import threading, time

def cpu_task(n):
    s = 0
    for i in range(n): s += i*i

N = 100_000_000

def run():
    threads = [threading.Thread(target=cpu_task, args=(N,)) for _ in range(4)]
    start = time.time()
    for t in threads: t.start()
    for t in threads: t.join()
    print(f'{time.time() - start:.2f} сек')

run()

— Python 3.13: ~13.5 сек
— Python 3.13t (без GIL): ~3.7 сек

✔️ Разница очевидна. Многопоточность наконец-то работает по-настоящему.

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

🪲 Промт дня: отлаживаем сложный Python-код и находим баг

Ваш код падает или даёт странный результат?

Сложный пайплайн, цепочка функций, куча вложенностей — непонятно, где именно всё ломается?

Попросите ChatGPT:

Вот мой Python-код. Помоги понять:
– Где может быть логическая ошибка или утечка
– Как упростить дебаг: добавить логгеры, трассировку, breakpoints
– Как использовать pdb, breakpoint(), icecream или rich
– Как логировать шаги пайплайна так, чтобы не утонуть в логе
– Как изолировать и проверить проблемный блок
– Какие edge-кейсы я, возможно, упустил
– Как ловить исключения правильно и писать meaningful ошибки

✅ Отлично работает при отладке ETL, API-обработчиков, ML-инференса, CLI-скриптов.

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

👓 Отслеживаем, какие ключи словаря в Python вы не использовали

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

Представьте, что у вас SQL-запрос вида:

SELECT fieldX, fieldY, fieldZ FROM ...

Но в итоговом CSV-экспорте вы используете только fieldX и fieldY. Как понять, что fieldZ остался неиспользованным?

✅ Класс TrackingDict

class TrackingDict(dict):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._accessed_keys = set()

    def __getitem__(self, key):
        self._accessed_keys.add(key)
        return super().__getitem__(key)

    @property
    def accessed_keys(self):
        return self._accessed_keys

    @property
    def never_accessed_keys(self):
        return set(self.keys()) - self._accessed_keys

Пример использования:

user = {
    "name": "John Doe",
    "age": 30,
    "email": "[email protected]",
}
user = TrackingDict(user)

assert user["name"] == "John Doe"

print("Использованные ключи:", user.accessed_keys)
print("Неиспользованные ключи:", user.never_accessed_keys)

Выведет:

Использованные ключи: {'name'}
Неиспользованные ключи: {'email', 'age'}

✅ Зачем это нужно

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

assert not user.never_accessed_keys, f"Вы не проверили {user.never_accessed_keys}"

✅ Типизированная версия:

from typing import TypeVar, Any

K = TypeVar('K')
V = TypeVar('V')

class TrackingDict(dict[K, V]):
    """
    Словарь с отслеживанием использованных ключей.
    """

    def __init__(self, *args: Any, **kwargs: Any) -> None:
        super().__init__(*args, **kwargs)
        self._accessed_keys: set[K] = set()

    def __getitem__(self, key: K) -> V:
        self._accessed_keys.add(key)
        return super().__getitem__(key)

    @property
    def accessed_keys(self) -> set[K]:
        return self._accessed_keys

    @property
    def never_accessed_keys(self) -> set[K]:
        return set(self.keys()) - self._accessed_keys

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

🔄 Breaking Changes в Python: как сделать их менее болезненными

На саммите Python Language Summit 2025 инженеры из Meta* поделились опытом массового деплоя Python-кода в прод и тем, как breaking changes усложняют жизнь разработчикам.

▶️ Суть проблемы

Breaking changes — это изменения в языке или стандартной библиотеке, которые ломают совместимость. Они неизбежны, но можно и нужно сделать их предсказуемыми и управляемыми.

▶️ Классификация breaking changes по «болезненности»

1️⃣ Легко находимые
— Можно найти через AST, grep, линтеры
— Примеры: удалённые функции, изменённые аргументы

2️⃣ Находятся при сборке/импорте
— Ошибки видны сразу при запуске или импорте
— Например: изменения в dataclasses в 3.12

3️⃣ Проявляются только во время исполнения
— Ошибки зависят от типа/значения
— Самые опасные: ловятся только тестами или в проде

▶️ Что можно улучшить

— Создать таксономию изменений по степени влияния
— Публиковать понятные гайды миграции, включая альтернативы и отличия API
— Сохранять документацию удалённых модулей
— Поддерживать тестирование на pre-release-версиях Python
— Разработать автоматические фиксаторы (например, с использованием Ruff)

▶️ Что обсуждали в комьюнити

— typing-extensions ломал pydantic: предлагали автоматические тесты зависимых проектов
— Успешный опыт pre-release CI у научного Python
— Идея: «экосистемные тесты» по dependency graph — проверять библиотеки заранее

💬 Вопрос на последок:

Что важнее: эволюция языка или стабильность экосистемы?

Напишите в комментарии или выберите реакцию:
🔥 — Лучше ломать, но двигаться вперёд
❤️ — Нет, стабильность важнее новых фич
👍 — Зависит от масштаба проекта

💥 Понравился пост? С ваc буст, а с нас больше топового контента!

Библиотека питониста #междусобойчик

* признанной экстремистской на территории Российской Федерации

🚀 От конкурсов к коду: как алгоритмическое мышление ускоряет приложения

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

🏆 Такие решения обычно находят разработчики с опытом спортивного программирования. В этом посте — почему их мышление так ценно для реальной разработки.

✅ Хотите узнать, как улучшить производительность приложений?

Читайте дальше: https://proglib.io/sh/BZ6EzqDbaW

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

🧩 Задача: неожиданный результат с изменением словаря

Что выведет следующий код?

def update_dict(d, key, value):
    d[key] = value
    return d

my_dict = {'a': 1, 'b': 2}
print(update_dict(my_dict, 'c', 3))
print(update_dict(my_dict, 'd', 4))
print(my_dict)

❓ Вопросы:
1. Какой будет вывод каждой из трёх строк?
2. Почему my_dict меняется после вызова функции?
3. Как изменить функцию, чтобы оригинальный словарь не менялся, а возвращалась новая копия с обновлённым значением?

Подвох:
Словари — изменяемые объекты, передаются по ссылке, поэтому любые изменения внутри функции влияют на оригинал.

Решение:

def update_dict(d, key, value):
    new_dict = d.copy()
    new_dict[key] = value
    return new_dict

Что проверяет задача:
✅ Понимание изменяемых объектов и передачи по ссылке в Python
✅ Умение создавать копии объектов для избежания побочных эффектов
✅ Навыки работы с функциями и аргументами

Библиотека питониста #междусобойчик

🐍 Свежие релизы Python‑пакетов за последние 7 дней

✅ Gymnasium 1.2.0 — новая версия «переименованного» Gym: единое API для RL‑задач и обширный набор окружений

✅ LangGraph 0.5.0 — фреймворк для построения stateful‑приложений с несколькими LLM‑акторами

✅ aioboto3 15.0.0 — асинхронная обёртка над boto3 для AWS

✅ lxml 6.0.0 — мощная обработка XML на базе libxml2/libxslt + ElementTree

✅ transformers 4.53.0 — SOTA‑модели для JAX, PyTorch и TensorFlow

✅ mcp 1.10.0 — SDK для Model Context Protocol

✅ chdb 3.4.0 — in‑process OLAP‑движок на ClickHouse

✅ Diffusers 0.34.0 — диффузионные модели в PyTorch и JAX

✅ junitparser 4.0.0 — манипуляция XML‑отчётами JUnit/xUnit

✅ Pybtex 0.25.0 — процессор BibTeX‑совместимых библиографий

✅ Instructor 1.9.0 — структурированный вывод из LLM

✅ Robyn 0.70.0 — супершустрый async‑фреймворк на Rust‑рантайме

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

🖥 Топ-вакансий для питонистов за неделю

Программист Python junior —‍ от 90 000 до 125 000 ₽, гибрид (Москва)

Python/ML Lead —‍ от 300 000 ₽, гибрид (Москва)

Senior Python Developer —‍ от 6 000 до 7 000 $, удалёнка

Backend разработчик (Python DRF), удалёнка

Python-разработчик (FastAPI/Django, Kafka, PostgreSQL) —‍ от 150 000 до 170 000 ₽, удалёнка


➡️ Еще больше топовых вакансий — в нашем канале Python jobs

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

🎮 Реализация собственного симулятора квантового состояния (Hume)

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

Решение: авторы предлагают построить пошаговый симулятор, реализованный на Python. Это не просто упражнение — это шанс «потрогать» основы: векторы состояния, гейты, измерения и крах симуляции при измерении. В репозитории из официального companion‑кода иллюстрируется весь процесс.

Ниже упрощённая версия – ключевые части симулятора из главы о квантовых состояниях:

import numpy as np

class QubitRegister:
    def __init__(self, n):
        self.n = n
        # старт: |0…0⟩
        self.state = np.zeros(2**n, dtype=complex)
        self.state[0] = 1.0

    def apply_gate(self, gate, target):
        """Применяет матричный gate к qubit 'target'"""
        full = 1
        for i in range(self.n):
            full = np.kron(full, gate if i == target else np.eye(2))
        self.state = full @ self.state

    def measure(self):
        probs = np.abs(self.state)**2
        outcome = np.random.choice(len(probs), p=probs)
        # Проекция на классическое состояние
        result = np.zeros_like(self.state)
        result[outcome] = 1.0
        self.state = result
        return bin(outcome)[2:].zfill(self.n)

# Использование:
qr = QubitRegister(2)
H = np.array([[1, 1], [1, -1]]) / np.sqrt(2)
qr.apply_gate(H, target=0)  # суперпозиция первого qubit
print("Перед измерением:", qr.state)
print("Измерено:", qr.measure())

Преимущества:

— Глубинное понимание формирования состояния и действия гейтов.
— Код открыт, минималистичен, легко адаптируется.
— Прекрасная демонстрация квантового измерения на уровне программиста.

🆖 Еще больше полезных книг — в нашем канале @progbook

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

🗳 Глобальные переменные, инкапсуляция и области видимости в Python

В Python область видимости (scope) определяет, где переменная видна и как долго живёт.

Основные области видимости:
📝 Локальная — внутри функции
📝 Глобальная — на уровне модуля
📝 Классовая/экземплярная — внутри класса (атрибуты класса и объекта)

🔎 Почему локальные переменные работают быстрее глобальных

Python ищет переменную по правилу LEGB: Local → Enclosing → Global → Built-in

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

Пример на замере времени:

import time

def local_test():
    a = 0
    for _ in range(1000000):
        a += 1

b = 0
def global_test():
    global b
    for _ in range(1000000):
        b += 1

start = time.time()
local_test()
print(f"Локальные переменные: {time.time() - start:.4f} сек")

start = time.time()
global_test()
print(f"Глобальные переменные: {time.time() - start:.4f} сек")


Локальные переменные: 0.5668 сек
Глобальные переменные: 1.1951 сек

✅ Результат: локальные переменные работают заметно быстрее.

🔎 Важно вспомнить об инкапсуляции — ключевом инструменте организации и оптимизации кода

Инкапсуляция:
📝 Локализует переменные внутри классов и функций
📝 Уменьшает количество отслеживаемых интерпретатором переменных
📝 Предотвращает конфликты имён и защищает данные
📝 Позволяет контролировать доступ к атрибутам через методы (getter/setter)

Пример сравнения класса с инкапсуляцией и без:

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height
    def area(self):
        return self.width * self.height

class EncapsulatedRectangle:
    def __init__(self, width, height):
        self._width = width
        self._height = height
    def get_width(self):
        return self._width
    def set_width(self, width):
        self._width = width
    def area(self):
        return self._width * self._height

✅ В реальных приложениях инкапсуляция помогает писать более надежный и поддерживаемый код.


🔎 Ключевые преимущества инкапсуляции и локальных переменных:

📝Снижение нагрузки на интерпретатор — быстрее выполняется код
📝 Улучшение управления памятью — локальные переменные освобождаются после выхода из функции
📝 Защита данных и уменьшение числа ошибок

🔎 Вывод

Для повышения производительности и удобства поддержки используйте локальные переменные и инкапсуляцию. Это простой, но мощный способ оптимизации вашего кода.

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

✅ Команда дня: отказ от Docker в пользу Python wheel-файлов для запуска проектов

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

В таком случае удобным решением становятся runnable-файлы — Python wheel, которые можно собрать с помощью Poetry и использовать в CI/CD.

Основные этапы настройки:

1️⃣ В файле pyproject.toml настроить включение необходимых пакетов при сборке wheel:

[tool.poetry]
packages = [
    { include = "main_dir" },
]

2️⃣ Создать в GCP Artifact Registry приватный репозиторий для хранения wheel-файлов.

3️⃣ В poetry.toml указать репозиторий для публикации:

[repositories.my-registry]
url = "https://europe-west1-python.pkg.dev/my-project/my-registry/"

4️⃣ Для публикации wheel-файла выполнить:

rm -fr dist/  # Удаление старых сборок для предотвращения конфликтов
sed -I.back 's/^version = "[^"]*"/version = "1.0.post'"$(date +%Y%m%d%H%M)"'"/' pyproject.toml  # Динамическое обновление версии
poetry publish --build --repository my-registry

5️⃣ Настроить VM для доступа к Artifact Registry с помощью команды:

gcloud artifacts print-settings python --project=my-gcp-project --repository=my-registry --location=europe-west1

6️⃣ Установить wheel на VM и запустить приложение:

pip install my-project
python -m my_job  # Запуск проекта

Преимущества такого подхода:
♋️ Отсутствие зависимости от Docker
♋️ Возможность прямого взаимодействия с железом и драйверами GPU
♋️ Легкость обновления через CI/CD
♋️ Минимальная прослойка между приложением и системой

✅ Использование wheel-файлов — отличная альтернатива Docker для Python-проектов в задачах, где нужна высокая производительность и прямой доступ к системе.

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