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

👉 @PythonPortal

Лучшие библиотеки Python 2026 года

Общего назначения

▪️ty — сверхбыстрый type checker нового поколения
▪️complexipy — измеряет сложность кода так, как её чувствует человек
▪️Kreuzberg — извлечение данных из 50+ форматов
▪️hrottled-py — rate limiting с 5 алгоритмами
▪️httptap — HTTP waterfall прямо в терминале
▪️ fastapi-guard — безопасность FastAPI без боли
▪️modshim — расширяй модули без monkey-patching
▪️Spec Kit — спецификации → рабочий код
▪️Skylos — dead code + уязвимости
▪️FastOpenAPI — OpenAPI для любого фреймворка

AI / ML / Data

▪️MCP Python SDK + FastMCP — стандарт интеграции LLM с инструментами
▪️TOON — JSON, оптимизированный под токены
▪️ Deep Agents — агенты с планированием и памятью
▪️ smolagents — агенты, которые думают кодом
▪️ LlamaIndex Workflows — event-driven AI workflows
▪️ Batchata — дешёвые batch-запросы к LLM
▪️ MarkItDown — любые файлы → Markdown
▪️ Data Formulator — анализ данных через natural language
▪️ LangExtract — точное извлечение сущностей из текста
▪️ GeoAI — ML + геоданные без боли

Детально, с примерами и разбором — в полной статье

👉 @PythonPortal

Ускорение процесса решето Эратосфена

1. Быстро вспомним алгоритм

Классическая реализация:

def eratosthenes(n):
    is_prime = [True] * (n + 1)
    is_prime[0] = is_prime[1] = False

    for i in range(2, int(n ** 0.5) + 1):
        if is_prime[i]:
            for j in range(i * i, n + 1, i):
                is_prime[j] = False

    return is_prime

Время — O(N log log N). Нас будет интересовать не асимптотика, а то, насколько можно ускорить чисто реализацией.

2. Оптимизация №1 — не трогаем чётные числа

Идея простая:

* все чётные, кроме 2, составные
* если работаем только с нечётными, уменьшаем массив и количество итераций примерно вдвое

Реализация:

def eratosthenes_odd(n):
    if n < 2:
        return []

    size = (n + 1) // 2
    is_prime = [True] * size
    is_prime[0] = False

    limit = int(n ** 0.5) // 2
    for i in range(1, limit + 1):
        if is_prime[i]:
            p = 2 * i + 1
            start = (p * p) // 2
            for j in range(start, size, p):
                is_prime[j] = False

    return is_prime

3. Оптимизация №2 — вместо list[bool] использовать bytearray

Мысль:

* bool в Python — это объект
* bytearray — плотно упакованный буфер
* меньше накладных расходов и лучше ложится в CPU cache

Пример:

def eratosthenes_bytearray(n):
    is_prime = bytearray(b"\x01") * (n + 1)
    is_prime[0:2] = b"\x00\x00"

    for i in range(2, int(n ** 0.5) + 1):
        if is_prime[i]:
            for j in range(i * i, n + 1, i):
                is_prime[j] = 0

    return is_prime

4. Оптимизация №3 — гибрид двух подходов

def eratosthenes_fast(n):
    if n < 2:
        return []

    size = (n + 1) // 2
    is_prime = bytearray(b"\x01") * size
    is_prime[0] = 0

    limit = int(n ** 0.5) // 2
    for i in range(1, limit + 1):
        if is_prime[i]:
            p = 2 * i + 1
            start = (p * p) // 2
            is_prime[start::p] = b"\x00" * (((size - start - 1) // p) + 1)

    return is_prime

5. Сравнение по времени

Тест на входе n = 10_000_000:

>>> eratosthenes.py
real  0.634s

>>> eratosthenes_odd.py
real  0.245s

>>> eratosthenes_bytearray.py
real  0.801s

>>> eratosthenes_fast.py
real  0.028s

Выводы:

* пропуск чётных (№1) даёт ~2.6× ускорение
* bytearray (№2) сам по себе не ускоряет — это больше про память
* гибрид (№3) даёт ~22.6× ускорение

Ключевой приём в №3:

is_prime[start::p] = b"\x00" * (((size - start - 1) // p) + 1)

Здесь нет Python-цикла — всё делает C-уровневая операция над слайсом. На таких задачах это огромная разница.

Общая мысль: в Python чаще всего ускоряют не асимптотику, а модель памяти и количество проходов по данным. Циклы + память → главные факторы.

👉 @PythonPortal

😅😅😅

👉 @PythonPortal

Мы рады представить Pocket TTS — text-to-speech модель на 100 млн параметров с качественным голосовым клонированием, которая запускается прямо на ноутбуке без GPU. Открытая, лёгкая и очень быстрая.

— так представили новую text-to-speech модель 😁

Проблема текущего TTS:
❌огромные LLM-модели (1B+ параметров) требуют GPU
❌маленькие модели типа Kokoro (82M) быстрые, но не умеют гибко клонировать голос

Pocket TTS закрывает этот разрыв. Она работает быстрее реального времени на обычном ноутбучном CPU, сохраняя мощность крупных моделей.

Настоящее голосовое клонирование: Pocket TTS нужно всего 5 секунд аудио, чтобы уловить:
✅тембр конкретного голоса
✅ эмоцию и акцент
✅акустические условия (реверб, качество микрофона)

Можно использовать их библиотеку голосов или клонировать голос из крошечного сэмпла.

Цифры это подтверждают. Несмотря на размер (100M параметров), Pocket TTS обходит F5-TTS и DSM по Word Error Rate (1.84) и по Audio Quality ELO. Это единственная модель в своём классе, которая умеет клонировать голос и при этом спокойно работает на CPU.

Как это удалось? Они отказались от дискретных токенов. Pocket TTS построена на Continuous Audio Language Models (CALM) и предсказывает последовательности непрерывных латентов напрямую, используя одношаговый sampling (Lagrangian Self-Distillation). CALM paper: …

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

👉 @PythonPortal

Разработчик поделился приятной находкой: сделали утилиту на Python с открытым кодом для офлайн-транскрибации аудио.

Назвали Buzz. Поддерживает аудио, видео, YouTube-линки и даже микрофон. На выход можно получить текст в txt, srt или vtt. Всё работает локально, без отправки куда-то на сервера.

Исходники лежат тут 🤪

👉 @PythonPortal

AI → JSON → UI: представили json-render

UI, который генерит ИИ. Выход детерминированный.

1. Определяешь каталог компонентов

2. ИИ стримит JSON

3. Рендеришь интерактивный UI

Пользователь может по промпту собирать дашборды, виджеты и целые мини-приложения, но в пределах тех компонентов и экшенов, которые ты заранее разрешил.

И это вышло в опенсорс.

👉 @PythonPortal

В CPython ускорили reference counting

В CPython основа управления памятью это reference counting: у каждого объекта есть счётчик ссылок, и при каждом “взял/отпустил” он инкрементится/декрементится. В цикле, который крутится очень много раз, это превращается в ощутимый оверхед и лишние записи в память (да, даже чтение переменной = запись из-за refcount).

С Python 3.14 добавили новую байткод-инструкцию: LOAD_FAST_BORROW.

Что меняется:

- раньше LOAD_FAST грузил локалку и поднимал refcount
- теперь LOAD_FAST_BORROW грузит локалку без инкремента
- есть ещё “склеенные” опкоды типа LOAD_FAST_BORROW_LOAD_FAST_BORROW (две загрузки за один opcode)

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

- меньше дергаем refcount в hot-path
- меньше мусора в CPU cache
- быстрее на циклах, где ты постоянно читаешь одни и те же локальные переменные

Но оптимизация включается не всегда. CPython применяет её только когда может доказать безопасность через статический анализ времени жизни (по CFG):

- значение используется “локально” и быстро потребляется
- не утекает в heap/генераторы/кадры
- источник не перезаписывается так, чтобы сломать “borrow”

Это похоже на упрощённые Rust lifetimes/borrowing, только на уровне байткода.

👉 @PythonPortal

Что если бы ты мог увидеть всё дерево зависимостей одной командой?

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

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

Ключевые возможности:

✅Полная визуализация зависимостей
✅Помечает зависимости, для которых есть доступные обновления
✅Показывает, какие пакеты зависят от конкретной библиотеки
✅Фильтрует дерево, чтобы показать только зависимости выбранного пакета

Установка uv: pip install uv

👉 @PythonPortal