Находки в опенсорсе: EasyP – тулбокс для ProtoBuf файлов

https://www.youtube.com/watch?v=XI-dNpM77iM

easyp – пакетный менеджер, билд-система и линтер для .proto файлов.
Хоть easyp и написан на #go 😱, одна из его фишек в том – что вы можете использовать любые плагины для генерации финального кода: он может быть хоть на #python, хоть на #rust.

Если много используете ProtoBuf – обязательно для ознакомления!

Как оно работает?

# Секция для правил линтера:
lint:
  use:
    - DEFAULT

# Секция с зависимостями:
deps:
  - github.com/googleapis/googleapis
  - github.com/grpc-ecosystem/grpc-gateway@v2.20.0

# Секция для правил сборки и генерации итоговых файлов:
generate:
  plugins:
    - name: go
      out: .
      opts:
        paths: source_relative
    - name: go-grpc
      out: .
      opts:
        paths: source_relative
        require_unimplemented_servers: false

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

Что будет в видео?

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

А еще в видео кот на гитаре играет!

Репозиторий: https://github.com/easyp-tech/easyp
Документация: https://easyp.tech
Чатик сообщества: @easyptech

Поставьте пацанам звездочек, если проект понравился!

Обсуждение: Какие инструменты для ProtoBuf вы используете? Какие есть пролемы? Что можно было бы добавить в качестве новой фичи в easyp?

| Поддержать | YouTube | GitHub | Чат |

Набор новых интересных PEPов и обсуждений для 3.15+

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

JIT и FT

https://github.com/python/cpython/issues/139038

Описывает планы на 3.15 и 3.16 по развитию JIT.
Самое важное планируют:
- Сделать JIT на 5-10% быстрее для всех случаев, до 50% скорости для краевых случаев
- Трассирующий JIT: https://github.com/python/cpython/issues/139109
- Поддежка Free-Threading режима: https://github.com/python/cpython/issues/133171
- К 3.16 планируют найти еще 2х меинтейнеров, потому что сейчас очень мало людей работают над джитом. Если всегда хотели - присоединяйтесь!

https://discuss.python.org/t/pre-pep-safe-parallel-python/103636

Обсуждение по будущему FT и subinterpreters как практических концепций.
Марк Шеннон предлагает сделать из Python Erlang 🌚

Каждому объекту предлагают добавить:
- Метод __freeze__() в большинство классов, чтобы делать объект иммутабельным (чтобы можно его было шарить между потоками и интерпретаторами)
- Метод __protect__(self: Self, obj: T) -> T, чтобы помечать объекты как "защищенные". Их можно менять, но с мьютексом
- И сам __mutex__, чтобы работать с защищенными объектами

https://discuss.python.org/t/add-virtual-threads-to-python/91403

Еще одно предложение от Марка – virtual threads в Python!
Кажется, что не только мне не нравится asyncio.

Обсуждение на очень раннем шаге, можно принять участие :)

PEPs

https://peps.python.org/pep-0798 позволит нам писать вот такой код:

list_of_lists = [[1, 2], [3, 4]]
flat_list = [*l for l in list_of_lists]

Если ПЕП примут, то можно будет делать unpacking прямо в comprehension. Не надо будет делать цикл или городить всякое сложное внутри. Крутое предложение, думаю, что его примут.

https://peps.python.org/pep-0799

Кратко:
- Добавляет пакет profiling в CPython
- Чистый питоновский profile теперь deprecated
- В 3.15 добавили profiling.sampling
- cProfile теперь будет доступен еще и как profile.tracing

https://peps.python.org/pep-0728

Добавляет такую возможность в TypedDict:

class Movie(TypedDict, extra_items=str):
     name: str
     rating: float
     year: int

Что значит, что три ключа имеют явный тип, любые другие ключи имеют fallback тип str. Что удобно, если у нас гигантский json с кучей похожих полей, например.

И конечно можно будет указать такое:

class Movie(TypedDict, closed=True):
     name: str
     rating: float
     year: int

Что будет значить, что никаких других ключей в словаре быть не может. Джва года ждал такую фичу!

https://peps.python.org/pep-0791 предлагает добавить новый модуль в Python: intmath

Решает старые проблемы модуля math. Если интересуетесь математикой в питоне – ПЕП для вас.

Обсуждение: как вам такой формат со ссылками? Что вы больше всего ждете из списка выше? Какие фичи вас бесят?

| Поддержать | YouTube | GitHub | Чат |

Записи с нашей бесплатной конфы в Нижнем подъехали!

Во-первых, хочу еще раз повторить слова благодарности всем: организаторам и волонтерам, спикерам, участникам. Отдельно хочу отметить тех, кто поддержал конфу анонсами. Приехало и пришло очень много людей: 1100+ регистраций, почти 600 человек на площадке. Вы все крутые!

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

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

Конкуренция за звание "лучшего" доклада – высочайшая. Выбирать будем не по каким-то там голосованиям, которые ни на что не влияют, а по просмотрам на ютюбе. Поддержите спикеров и меня просмотрами :)

Выкладываю записи сразу, а не через полгода.

Доклады в порядке выступлений:
- Чего вы не знали о строках в Python? Василий Рябов
- ИИ-агенты в каждый дом, Алексей Порядин @sw1logs
- Генератор байткода и байткод генератора, Михаил Ефимов
- Внутреннее устройство сборки мусора в CPython 3.14+, Сергей Мирянов
- Проектирование — это когда чувствуешь, а не какие-то там циферки, Николай Хитров @nkhitrov_blog
- Дотянуться до кремния. HighLoad Python: SIMD, GPU – Пётр Андреев @py_up
- Continuous profiling, Давид Джалаев @dzhalaevd_blog
- Vim — это метаредактирование, Илья Ильиных @kydavoiti

Но, на конфе были и минусы :)
Следующий раз постараемся поправить шум от стендов (мешали в большом зале), записать все доклады (сейчас только один зал), пригласить еще больше гостей.

Наша традиционная вечеринка собрала полный бар людей, было очень весело. Отлично посидели, погуляли, поболтали. Лучшее сообщество!

При поддержке:
- https://it52.info
- https://itgorky.ru

Обсуждение: Кто был? Как вам конфа? Как вам Нижний Новгород?
Если понравилось: напишите приятное организаторам и спикерам. Если не понравилось – пишите вашу критику. Будем делать лучше.

| Поддержать | YouTube | GitHub | Чат |

Минусы Litestar

Внезапно вспомнил, что я меинтейнер фреймворка Litestar.
Для тех, кто пропустил:

> Litestar не является микро-фреймворком. В отличие от таких фреймворков, как FastAPI, Starlette или Flask,
> Litestar изначально включает множество функций, необходимых для типичного современного веб-приложения,
> таких как интеграция с ORM, клиентские и серверные сессии, кэширование, поддержка OpenTelemetry и многое другое.

from dataclasses import dataclass
from litestar import Litestar, post

@dataclass
class User:
    name: str

@post(path="/")
async def index(data: User) -> User:
    return data

app = Litestar(route_handlers=[index])

И он классный:
- Быстрый
- Работает с Pydantic, msgspec и даже базовые dataclasses в качестве моделей
- Предоставляет базовые примитивы для работы с логикой: DTOs, Repository, Service (часть из них в advanced_sqlalchemy, очень удобно для крудов)
- Умеет из коробки в аутентификацию, метрики, DI, CORS, CSRF, кеширование, логирование, мониторинг, вебсокеты, htmx, сессии, загрузку файлов, разные ORMки и много всего еще
- Можно делать не только API, но и нормальные шаблончики
- Он с нами уже несколько лет, он работает
- А еще его делает большая команда, а не один человек

Кароче, просто лучший фреймворк (кроме Django, конечно).

Но! Сегодня речь пройдет про минусы. Которые скоро пофиксят в v3 (или которые все еще будут с нами)

Минусы

1. Самое главное: DI на именах. Да. Вот так:

class UserController(Controller):
    path = "/user"
    dependencies = {"user": Provide(retrieve_db_user)}

    @patch(path="/{user_id:uuid}")  # <- тут тоже можно указывать `dependencies`
    async def get_user(self, user: User) -> User: ...

Что очень плохо. Тип user, который мы указываем в dependencies и в параметрах может не совпасть. Есть некоторая валидация для такого в рантайме, но все равно очень рисково.

Планы? Я предложил использовать dishka в качестве дефолтного DI, а старый задеприкейтить.

Высказать свое обоснованное мнение можно тут (или просто лайкнуть пост): https://github.com/orgs/litestar-org/discussions/4377

Хочу верить, что мы сможем поправить данную проблему в v3, ваши голоса – могут помочь :)

2. DI в middleware. А точнее отсутствие DI в middleware. Пока что приходится прокидывать зависимости через app.state, что очень криво. Данная проблема признана ошибкой дизайна и будет исправлено в v3, ура!

3. Своя схема для OpenAPI. Litestar переписал дефолтную схему pydantic, что позволило использовать более строгую схему, но переодически новые типы отваливаются. Например, pydantic.Json не обработан, имеет кривую схему. Сейчас мы обсуждаем стоит ли откатиться до дефолтной схемы. Стоит ли?

4. PydanticPlugin игнорирует ConfigDict, который объявлен в самой моделе, в v3 будет пофикшено. Сейчас параметры вроде by_alias и round_trip надо передавать в плагин. Что свело меня с ума, искал ошибку несколько часов

5. CLI местами разваливается, очень много багов и плохая читаемость

6. Очень сырая документация. Очень плохая навигация и структура, очень мало примеров, мало людей ее читало, мало людей находило проблемы, мало людей присылало PRы. Тут нужна ваша помощь очень сильно!

Итог

Отличный фреймворк, у которого есть некоторое количество детских проблем и ошибок проектирования. Но что отличает? Про них говорят, их исправляют.
Полный роадмап для версии v3: https://github.com/litestar-org/litestar/issues/4009

Обсуждение: Как вам Litestar? Какие минусы я забыл? Каких фичей не хватает? Что показалось сложным? Буду рад обратной связи :)

PEP 810: Explicit lazy imports

На обсуждение вышел новый PEP, который предлагает добавить в Python 3.15 новый вид импортов.

https://peps.python.org/pep-0810/

lazy import json
lazy from json import dumps

Как будет работать?

Импорты не будут подгружаться до момента первого обращения к объекту.

import sys

lazy import json

print('json' in sys.modules)  # Модуля еще нет 

# Загрузка начинается вот тут:
result = json.dumps({"hello": "world"})

print('json' in sys.modules)  # Теперь он загружен

Зачем?

- Быстрее загружать модули
- Позволит убрать много импортов из функций / методов
- Позволит убрать if TYPE_CHECKING: import some_module, было множество предложений по добавлению import type конструкции, пример: https://discuss.python.org/t/type-only-imports/96755
- Позволит решать циклические импорты
- Убирает необходимость в LazyLoader и страшных вещей вроде https://scientific-python.org/specs/spec-0001

Детали реализации

Планируется добавить:
- Функцию __lazy_import__ (аналог __import__ для импорта )
- Специальный атрибут на уровне модуля __lazy_modules__, где будут храниться ленивые импорты текущего модуля
- types.LazyImportType как тип нового "ленивого" модуля (аналог `types.ModuleType`)
- sys.lazy_modules для списка ленивых модулей глобально
- sys.set_lazy_imports_filter для глобальных настроек импортов, что? 🤯
- Байткод IMPORT_NAME получит флаг, является ли импорт ленивым
- Ошибки в именах модулей тоже будут ленивыми https://peps.python.org/pep-0810/#reification

Из забавного: import * не будет доступен в lazy режиме.

# SyntaxError: lazy from ... import * is not allowed
lazy from json import *

Реализация: https://github.com/LazyImportsCabal/cpython/tree/lazy

Обсуждение: как вам?

Бонус: меня тут в комментах спрашивают, куда я пропал. Я пропал в опенсорсе, пилю django-modern-rest. Простую и удобную библиотеку для REST API в Django. Пока на стадии pre-alpha, но уже скоро будет первый релиз. Можно уже ставить ⭐, чтобы потом всем говорить, что первыми узнали про новую модную штуку!

https://github.com/wemake-services/django-modern-rest

| Поддержать | YouTube | GitHub | Чат |

minimal vscode: убираем / кастомизируем status bar

https://www.youtube.com/watch?v=H5iVQZNk92s

В статусбаре в vscode – очень много всего: как полезного, так и лишнего.
Сегодня посмотрим, как можно его кастомизировать:
- Можно просто спрятать (как делаю я)
- Можно очень детально кастомизировать
- Можно перенести часть его функций в плагины

И вот тут главная фича vscode выходит наружу – у нас ведь просто браузер с html / css / js.
А значит, мы можем использовать css и js для кастомизации всего!
И оно будет работать одинаково даже в cloud версиях IDE.

В выпуске:

- Будем писать CSS для удаления лишнего из status bar

"custom-ui-style.stylesheet": {
  "#status\\.problems": {
    "visibility": "hidden !important",
    "display": "none !important",
  }
}

- И создавать локальные плагины на #javascript для кастомизации поведения редактора

function updateColumnPosition() {
    const positionLabel = document.querySelector(
      '#status\\.editor\\.selection .statusbar-item-label',
    )
    if (!positionLabel || !positionLabel.textContent) {
      // It might not exist for some reason ¯\_(ツ)_/¯
      return
    }

    const currentLine = document.querySelector(
      '.line-numbers.active-line-number',
    )

    // Now we would have the column position instead of the active line number:
    const colNumber = positionLabel.textContent.match(/Col (\d+)/)
    currentLine.textContent = colNumber[1]
}

Впереди еще пара взрывающих мозг видосов, будем и дальше превращать vscode в Черный Квадрат Малевича.
В следующих видео:
- Уберем оставшиеся части UI
- Сделаем свою тему, нативная интеграция самой минималистичной темной темы от меня (есть для vscode и nvim): https://github.com/pustota-theme/pustota
- Поговорим про git
- Научимся пользоваться дебагером, как будто мы трухацкеры

Обсуждение: То что vscode - браузер - плюс или минус лично для вас? И почему?

| Поддержать | YouTube | GitHub | Чат |

Breaking news

В CPython предлагают добавить Rust: https://discuss.python.org/t/pre-pep-rust-for-cpython/104906

Пример кода: https://github.com/emmatyping/cpython/pull/13/files

#[unsafe(no_mangle)]
pub unsafe extern "C" fn b64encode(
    _module: *mut PyObject,
    args: *mut *mut PyObject,
    nargs: Py_ssize_t,
) -> *mut PyObject {
    if nargs != 1 {
        unsafe {
            PyErr_SetString(
                PyExc_TypeError,
                c"b64encode() takes exactly one argument".as_ptr(),
            );
        }
        return ptr::null_mut();
    }

    let source = unsafe { *args };
    let buffer = match unsafe { BorrowedBuffer::from_object(source) } {
        Ok(buf) => buf,
        Err(_) => return ptr::null_mut(),
    };

    let view_len = buffer.len();
    if view_len < 0 {
        unsafe {
            PyErr_SetString(
                PyExc_TypeError,
                c"b64encode() argument has negative length".as_ptr(),
            );
        }
        return ptr::null_mut();
    }
    let input_len = view_len as usize;
    let input = unsafe { slice::from_raw_parts(buffer.as_ptr(), input_len) };

    let Some(output_len) = encoded_output_len(input_len) else {
        unsafe {
            PyErr_NoMemory();
        }
        return ptr::null_mut();
    };

    if output_len > isize::MAX as usize {
        unsafe {
            PyErr_NoMemory();
        }
        return ptr::null_mut();
    }

    let result = unsafe {
        PyBytes_FromStringAndSize(ptr::null(), output_len as Py_ssize_t)
    };
    if result.is_null() {
        return ptr::null_mut();
    }

    let dest_ptr = unsafe { PyBytes_AsString(result) };
    if dest_ptr.is_null() {
        unsafe {
            Py_DecRef(result);
        }
        return ptr::null_mut();
    }
    let dest = unsafe { slice::from_raw_parts_mut(dest_ptr.cast::<u8>(), output_len) };

    let written = encode_into(input, dest);
    debug_assert_eq!(written, output_len);
    result
}

Все подробности будут в @cpython_notes

Обсуждение: что думаете?

| Поддержать | YouTube | GitHub | Чат |

Аллокаторы в СPython: база

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

Зачем вообще нужно много разных аллокаторов? Все они делают одно и то же: выделяют память в куче (heap). В зависимости от наших вариантов использования данной памяти - выделять и освобождать её нужно очень по-разному.

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

Например: при парсинге AST мы используем PyArena аллокатор. Он выделяет сразу много памяти, сразу вычищает все за один раз. Что идеально подходит для парсинга.

Но, для рантайма - задачи, конечно же другие. Там есть долгоживущие объекты, есть много мелких краткоживущих, есть довольно большие, есть маленькие. Для таких задач используют "general purpose allocators". Которые в среднем хороши во всем.

Дизайн аллокаторов в CPython

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

Документация:
- https://docs.python.org/3/c-api/allocation.html
- https://docs.python.org/3/c-api/memory.html

В CPython есть: malloc, pymalloc, mimalloc и некоторые их варианты для дебага.

Они разделены на три "домена" для аллокаторов, то с чем они работают, какие задачи решают:
- Raw: для выделения памяти для общих задач, например под сишные буферы или IO. Может работать без PyThreadState
- Mem: для выделения памяти для общих задач, но уже с PyThreadState, например под Python буферы, подходит для мелких объектов
- Object: для выделения памяти под конкретные мелкие объекты

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

А вот таблица, какие реальные аллокаторы используют те или иные C-API функции в разных режимах:

PyMem_RawMalloc -> malloc
PyMem_Malloc -> pymalloc
PyObject_Malloc -> pymalloc

Она правда немного устарела и не отражает Free-Threading сборки, которые требуют mimalloc 🌚
Кто первый успеет сделать PR с исправлением - тот молодец!
О mimalloc мы как-нибудь отдельно поговорим, там нужно рассказывать сильно глубже, в том числе про GC и PyGC_Head.

Зачем питону свой аллокатор?

В CPython есть (был? для free-threading он не используется и не будет) свой аллокатор: pymalloc, основная задача которого – работа с маленькими Python объектами.
Про него полностью тоже нужно писать большой отдельный пост.

Что вообще важно в аллокаторе?
- Стратегия выделения памяти под новый запрос
- Работа с округлениями размера памяти и выравнивание
- Дефрагментация памяти
- Стратегия очистки памяти

struct arena_object {
    uintptr_t address;
    pymem_block* pool_address;
    uint nfreepools;
    uint ntotalpools;
    struct pool_header* freepools;
    struct arena_object* nextarena;
    struct arena_object* prevarena;
};

Но кратко про pymalloc можно сказать следующее:
- Он создает арены по 1MB
- Внутри арены разделены на пулы по 16KB
- Внутри пулы поделены на блоки фиксированного размера

Зачем? Чтобы не аллоцировать часто маленькие кусочки памяти. Что дорого.

Можно ли управлять аллокаторами?

Да! Есть опции для сборки: --without-mimalloc, --without-pymalloc
И даже переменная окружения PYTHONMALLOC, которая позволяет указать, какой аллокатор использовать для всех случаев. Зачем? Прежде всего для дебага. Но можно потестить, вдруг будет давать буст по скорости или потреблению памяти в ваших вариантах использования.

Обсуждение: какой ваш любимый аллокатор? И почему jemalloc?

| Поддержать | YouTube | GitHub | Чат |