Почему Python наконец-то убирает GIL

GIL — Global Interpreter Lock — один глобальный мьютекс на весь интерпретатор CPython. Любой поток, который хочет выполнить Python-код, должен сначала захватить этот lock. Один lock = только один поток работает в любой момент времени.
​
➡️ Почему так сделали

В 1991 году, когда появился Python, многоядерных CPU практически не было. Потоки добавили в язык в середине 90-х, и вместо того чтобы защищать каждую внутреннюю структуру интерпретатора отдельным мьютексом — поставили один глобальный. Проще, быстрее, работает.
​

«Нам казалось, что мы нормально разобрались с потоками. Многоядерных процессоров тогда всё равно ни у кого не было» — Гвидо ван Россум

​
➡️ Когда это стало проблемой

Середина 2000-х: производители чипов упёрлись в потолок частоты и начали наращивать ядра. Внезапно concurrency без parallelism — это ограничение, а не фича.
​
➡️ Что меняется

Спустя 30+ лет процесс удаления GIL наконец запущен. Python сможет выполнять потоки параллельно. Кстати, если хочется parallelism прямо сейчас — можно использовать альтернативные интерпретаторы (например, на Rust), которые уже масштабируются на все ядра.

📎 Видео в посте или на YT

@zen_of_python

Напомнию, что есть канал по нейронкам, который ведёт тот же автор, что и этот канал. Это всё часть медиа Tproger, где я работаю.

⚡️ Основная фишка — на все свежие ИИ-релизы я делаю посты, чтобы вы могли читать только один канал. Иногда получается даже раньше официального запуска, чем я особенно горжусь :)

И есть моя любимая рубрика:
➡️ Обзор трендов Hugging Face за неделю с супер-кратким описанием моделей, выходит регулярно.

Иногда закидываю мемчики или что-то полезное для изучения (о, это очень крутая книга, рекомендую если раньше не видели).

Заходите и подписывайтесь: @neuro_channel

Состоялся релиз pyauto-desktop — современной замены PyAutoGUI с поддержкой HiDPI

Если автоматизировали десктоп через PyAutoGUI — знаете боль: скрипт ломается при смене разрешения, на 4K всё едет, мультимонитор не работает. Новая библиотека решает это.
​
Отличия от PyAutoGUI
🔘Автоскейлинг координат и изображений через Session-логику
🔘До 5x быстрее (mss + Pyramid Template Matching + кэширование)
🔘locateAny / locateAll из коробки вместо циклов
🔘Встроенный GUI Inspector: снипы, редактор, генерация кода
🔘Бэкенд: opencv-python, mss, pynput
​
Из комментариев

Session management, который абстрагирует DPI — это то, чего не хватало PyAutoGUI

​📎 Код на GitHub, на видео демо

@zen_of_python

Pyrethrin — exhaustive error handling для Python, теперь с обёртками для pandas/numpy/FastAPI

Библиотека, которая привносит Rust-стиль обработки ошибок в Python: нельзя проигнорировать исключение, компилятор (ну, рантайм) заставит обработать все варианты.

Новое в v0.2.0: Shields

Drop-in замены для библиотек с явным объявлением исключений:

# Было — исключения неявные
import pandas as pd
df = pd.read_csv("data.csv")

# Стало — нужно обработать все возможные ошибки
from pyrethrin.shields import pandas as pd
from pyrethrin import match, Ok

result = match(pd.read_csv, "data.csv")({
    Ok: lambda df: process(df),
    OSError: lambda e: log_error("File not found", e),
    pd.ParserError: lambda e: log_error("Invalid CSV", e),
    # ... остальные
})

➡️ Как узнали какие исключения бросает pd.read_csv?

Автор написал отдельный инструмент Arbor для статического анализа. Для read_csv он прошёл 5,623 функции и нашёл 1,881 raise-statement — 35 типов исключений. Топ: ValueError (442), TypeError (227), NotImplementedError (87).

➡️ Философия

🔘Нет unwrap() — никаких escape hatch, обрабатывай всё
🔘Проверка exhaustiveness в момент вызова, не импорта
🔘Работает с нативным match-case (Python 3.10+)

📎 GitHub, Arbor, PyPI

@zen_of_python

PCA — стандартный способ уменьшить размерность данных (1000 фичей → 50). Главная боль: нужно выбирать n_components — сколько компонент оставить. Обычно либо перебор через GridSearch, либо «ну возьму 50, должно хватить». Библиотека randomized-svd решает проблему автоматически.

🔘Сама определяет, где заканчивается сигнал и начинается шум
🔘Отрезает лишнее без ручного подбора
🔘Один проход вместо кросс-валидации

➡️ Бонус для больших данных

PCA требует центрирования матрицы. Если матрица разреженная (sparse), центрирование делает её плотной — память взрывается. Библиотека умеет считать PCA на sparse-матрицах без этой проблемы.
​
Использование

from randomized_svd import RandomizedSVD

rsvd = RandomizedSVD(n_components=100, rank_selection='auto')
X_reduced = rsvd.fit_transform(X)  # сама выберет сколько компонент нужно

Drop-in замена sklearn — работает в Pipeline.
​
📎 Код на GitHub, доки

@zen_of_python

calgebra — алгебра множеств для календарей в Python

Есть задача: найти время, когда вся команда свободна, с учётом Google Calendar, .ics файлов и рабочих часов. Обычно это превращается в ад из циклов и условий. Новый проект решает это через операторы множеств — как будто пишешь SQL, но для временных интервалов.

Как это работает

from calgebra import day, time_of_day, HOUR

# Рабочие часы
work_hours = day("weekday") & time_of_day(start=9*HOUR, duration=8*HOUR)

# Календари команды
team = alice | bob | charlie

# Свободное время для встречи от 2 часов
free = (work_hours - team).filter(hours >= 2)

Операторы: | (объединение), & (пересечение), - (разность), ~ (дополнение). Ленивые вычисления — выражение выполняется только при слайсинге.

➡️ Чем отличается от аналогов

🔘icalendar / ics.py — только парсят .ics, calgebra добавляет запросы и композицию
🔘gcsa — CRUD для Google Calendar, calgebra даёт set-операции поверх
🔘dateutil.rrule — генерирует повторения, но не умеет пересекать/вычитать таймлайны

➡️ Фичи

🔘Поддержка RFC 5545 (повторяющиеся события)
🔘Фильтры по длительности, метаданным, кастомным атрибутам
🔘Импорт/экспорт .ics через file_to_timeline и timeline_to_file
🔘Интеграция с Google Calendar
🔘Type hints для IDE и агентов

➡️ Кому пригодится

Разработчикам scheduling-фич, интеграций с календарями, систем проверки availability. Автор отмечает, что API удобен для ИИ-агентов благодаря композируемости и типизации.

📎 Код на GitHub, на видео демо работы ИИ-агента с calgebra

@zen_of_python

Если взять конкретный язык, то всё может быть ещё хуже.

В Python, например, тип bool наследуется от int, поэтому True и False — это полноценные объекты — целые числа. Каждый объект в CPython несёт накладные расходы:
🔘PyObject header — счётчик ссылок + указатель на тип (~16 байт на 64-бит)
🔘PyLongObject — структура для хранения целых чисел произвольной длины (~12 байт дополнительно)

Можно проверить самостоятельно:

import sys
print(sys.getsizeof(True))   # 28
print(sys.getsizeof(False))  # 28

Почему так расточительно?
Python оптимизирован для удобства и гибкости, а не для экономии памяти. Зато True и False — синглтоны (существует только по одному экземпляру каждого), так что в реальных программах это не создаёт проблем.

Для компактного хранения множества булевых значений используют numpy.array с dtype=bool (1 байт на значение) или битовые массивы.

@devs_books