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

👉 @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

Коллекция книг по машинному обучению и искусственному интеллекту в формате PDF: забираем

👉 @PythonPortal

Когда джун всё таки переписал проект на своём языке

👉 @PythonPortal

Лучшие репозитории GitHub для изучения ИИ с нуля в 2026 году:

1. Андрей Карпаты
https://github.com/karpathy/nn-zero-to-hero

2. Hugging Face Transformers
https://github.com/huggingface/transformers

3. FastAI/fastb
https://github.com/fastai/fastbook

4. Made-With-ML
https://github.com/GokuMohandas/Made-With-ML

5. ML System Design
https://github.com/chiphuyen/machine-learning-systems-design

6. Awesome Generative AI guide(
https://github.com/aishwaryanr/awesome-generative-ai-guide

7. Dive into Deep Learning
https://github.com/d2l-ai/d2l-en

👉 @PythonPortal

Топ-5 алгоритмов rate limiting, которые стоит знать:

➡️Token Bucket
Ведро пополняется токенами с фиксированной скоростью. Каждый запрос съедает 1 токен.
Если токенов нет (ведро пустое) -> запрос троттлится.
Отлично, когда надо разрешить короткие всплески, но держать среднюю скорость запросов.

➡️Fixed Window Counter
Делит время на фиксированные окна (например, по минуте).
Считает запросы в текущем окне. Если счётчик превысил лимит -> блок.
Просто внедрить, но есть проблема со всплесками на границах окон.

➡️Leaky Bucket
Представь очередь, которая “протекает” с постоянной скоростью.
Если новые запросы переполняют очередь -> они дропаются.
На выходе получается ровный, предсказуемый поток запросов.

➡️Sliding Window Log
Хранит timestamp для каждого запроса.
На каждый новый запрос выкидывает старые timestamp’ы за пределами окна и считает оставшиеся.
Очень точно, но дороговато по памяти на больших объёмах.

➡️Sliding Window Counter
Гибрид Fixed Window и Log.
Делит окно на мелкие бакеты и считает скорость через взвешенную сумму.
Хороший баланс точности и расхода памяти.

Какой из них вы чаще всего используете в проде?

👉 @PythonPortal

Обесценивание профессии "инженер":

👉 @PythonPortal

Расширенный алгоритм Евклида.

1) Что такое расширенный алгоритм Евклида

Для двух целых чисел a и b и их НОД, то есть gcd(a, b), выполняется линейное уравнение с двумя переменными:

a·x + b·y = gcd(a, b) (1)

Расширенный алгоритм Евклида это способ найти одну пару целочисленных решений (x, y), которая удовлетворяет (1).

2) Алгоритм расширенного алгоритма Евклида

Перед тем как перейти к сути, вспомним обычный алгоритм Евклида.

Для двух целых a и b следующими шагами получаем:

gcd(a, b) = rₙ (2)

Сама цепочка делений с остатком:

a = b·q₀ + r₀
b = r₀·q₁ + r₁
r₀ = r₁·q₂ + r₂
...
rₙ₋₂ = rₙ₋₁·qₙ + rₙ
rₙ₋₁ = rₙ·qₙ₊₁

Теперь посмотрим на первую строку:

a = b·q₀ + r₀
r₀ = a − b·q₀

То есть r₀ можно выразить как линейную комбинацию a и b.

Подставим это во вторую строку:

b = r₀·q₁ + r₁
b = (a − b·q₀)·q₁ + r₁
b = a·q₁ − b·q₀·q₁ + r₁
r₁ = −a·q₁ + b·(q₀·q₁ + 1)

Получается, r₁ тоже выражается через a и b.

Если повторять эту операцию, то каждый rᵢ (0 ≤ i ≤ n) можно представить как сумму кратных a и b.
Значит, в конце:

rₙ = k·a + l·b

А из (2) получаем:

k·a + b·l = gcd(a, b) (3)

Это та же форма, что и (1). Сравнивая (1) и (3), получаем:

(x, y) = (k, l)

и эти k и l будут одной из пар целочисленных решений.

3) Реализация расширенного алгоритма Евклида

Опираясь на вышеописанное, реализуем расширенный алгоритм Евклида:

# extended_eucledean.py
def extended_eucledean(a, b):
  if b == 0:
    return (1, 0)
  else:
    xd, yd = extended_euclid(b, a % b)
    return (yd, xd - a // b * yd)

Очень просто, правда?

Ну всё. Пока. 🛌

👉 @PythonPortal