👏 Конфиги по-человечески: CueLang, Starlark и боль Python-разработчика

Когда проект растёт, обычные .toml, .yaml и .json превращаются в кошмар — без импортов, функций, комментариев и валидации.

CueLang решает почти всё: строгая типизация, DRY, схемы и экспорт в JSON/YAML. Но беда — только Go, без питонячих биндингов.

А вот Starlark неожиданно оказался достойной альтернативой:
— безопасен (песочница, без доступа к FS и сети);
— расширяем (можно подключать Python-функции);
— даёт контроль над импортами и окружением;
— похож на Python, но только внешне — внутри это совсем другой зверь.

Пример:

import starlark

with open("config.star") as f:
    code = f.read()

module = starlark.Module()
stdlib = starlark.Globals.standard()
ast = starlark.parse("config.star", code)
starlark.eval(module, ast, stdlib, None)

Starlark — не замена CueLang, а отличный инструмент, если нужно встроить безопасный DSL в продукт.
Но для личных проектов — Python + Pydantic всё ещё проще и удобнее.

📱 Репозиторий

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

#буст

🔥 Официально утверждены два новых PEP: PEP 798 и PEP 810

1️⃣ PEP 798 — Unpacking in Comprehensions

Теперь в Python 3.15 можно будет использовать распаковку прямо в comprehensions (списковых, словарных и генераторных выражениях).
Python Steering Council внёс небольшое уточнение — и потребовал использовать явные циклы вместо yield from, чтобы сохранить простоту и симметрию между синхронными и асинхронными выражениями.

💡 Это сделает comprehensions более мощными и при этом предсказуемыми.

2️⃣ PEP 810 — Explicit Lazy Imports

Наконец-то появятся явные ленивые импорты через ключевое слово lazy.
Теперь можно будет писать:

lazy import numpy  
from pandas lazy import DataFrame

Импорт произойдёт только при первом обращении к модулю, что ускорит запуск и сократит время старта больших проектов.
Также добавят sys.get_lazy_imports() и уточнят приоритет между флагами среды (PYTHON_LAZY_IMPORTS, -X, sys.set_lazy_imports()).

👍 Оба улучшения появятся в Python 3.15 — релиз, который явно принесёт много приятных сюрпризов разработчикам.

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

#буст

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

#развлекалово

➡️ PyTogether — Google Docs для Python

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

Основные фишки:
— Совместное редактирование кода в реальном времени (на Y.js)
— Безопасная авторизация — вручную или через Google
— Группы и проекты — удобно организуйте командную работу
— Рисование прямо в IDE — идеально для преподавателей
— Подсветка и линтинг — помогает писать чистый код
— Чат и голосовые комнаты — как в Discord, прямо внутри проекта
— Умное автосохранение — ничего не потеряется

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

🔗 Github

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

#буст

💡 Как часто Python делает аллокации

Короткий ответ — очень часто.

🐁 Каждое число — объект

В CPython каждое целое число — это объект PyLongObject*, хранящийся в куче. Даже операция i + 1 создаёт новый объект.

Если бы каждое число выделялось через malloc/free, арифметика была бы в сотни раз медленнее, чем машинная инструкция ADD.

Но Python применяет несколько хитрых оптимизаций.

Добавим вывод в функцию аллокации чисел и запустим код:

for i in range(0, 100_000):
    print(i + 1)

Результат:

Allocating number object 100904 times

Кажется, создаётся новый объект на каждой итерации.
Но без print():

for i in range(0, 100_000):
    a = i + 1

Теперь:

Allocating number object 905 times

То есть новые объекты создаются редко — большинство просто переиспользуются.

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

Функция сложения в CPython выглядит примерно так:

static PyLongObject *
long_add(PyLongObject *a, PyLongObject *b)
{
    stwodigits z = medium_value(a) + medium_value(b);
    return _PyLong_FromSTwoDigits(z);
}

_PyLong_FromSTwoDigits решает, брать ли объект из freelist (списка свободных объектов) или выделять новый:

PyLongObject *v = _Py_FREELIST_POP(PyLongObject, ints);
if (v == NULL) v = PyObject_Malloc(sizeof(PyLongObject));

После освобождения объект возвращается обратно во freelist, а не в систему.

Результат эксперимента:

102 ALLOCATING
99193 REUSING

99% чисел просто переиспользуются!

🐁 Малые числа предсозданы

Для диапазона -5..1024 объекты создаются заранее:

PyLongObject small_ints[_PY_NSMALLNEGINTS + _PY_NSMALLPOSINTS];

Такие числа никогда не аллоцируются — просто возвращаются из таблицы. Это ещё одна оптимизация CPython.

🐁 Как Python управляет памятью

CPython использует собственный пуловый аллокатор (pymalloc). Память разбита на пулы фиксированного размера (по 256 КБ).
Выделение из пула выполняется почти мгновенно, без системных вызовов malloc() или mmap().
Физическая память подгружается лениво — по мере использования.

🐁 На практике это значит: Python «аллoцирует» очень часто, но реальных системных аллокаций почти нет.

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

#буст

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

#развлекалово

📦 Управление зависимостями Python с помощью `uv` (наглядно)

В экосистеме Python существует множество форматов для управления зависимостями — requirements.txt, pyproject.toml, uv.lock и другие.

С помощью `uv` можно управлять почти всеми из них — легко переходить между состояниями, обновлять, синхронизировать и восстанавливать окружения.

На графике показано, как именно можно переходить от одного состояния к другому с помощью команд uv.

> 💡 Примечание: “libs in env” обозначает установленные зависимости в виртуальном окружении, созданном через uv venv.

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

#буст

📱 Python новости за последние 7 дней

🧩 Чистый и безопасный код
— Как `with` делает Python-код безопаснее и читабельнее — пояснение работы контекстных менеджеров и best practices их использования.
— Код, за который не стыдно — практика чистописания: читаемый, поддерживаемый и аккуратный Python-код для начинающих.
— Сначала логика, потом код — как писать программы для ESP на MicroPython, правильно разделяя логику и реализацию.

⚙️ Веб, API и контейнеризация
— Как не положить API: rate limiting в Python — реализация ограничений по количеству запросов для защиты сервиса.
— Docker для Python-разработчика — как упаковать приложение в контейнер и запускать его где угодно.
— Библиотека для доступа к данным ЦБ: cbrapi — работа с финансовыми данными через Python, быстрый старт.

🌐 Проекты и инструменты
— Создаем GUI на Python с Flet — от простого скрипта до полноценного Markdown-редактора.
— Создаем свой create-react-app на Python — интерактивный генератор проектов с Typer и Questionary для быстрого старта.

🧠 Карьерные и трендовые темы
— Особенности Python для собеседований. Часть 2 — на что точно обратят внимание на техническом интервью.
— Почему Python так популярен в 2025 году — анализ трендов, причин популярности и перспектив развития языка.

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

#свежак

📅 Предложение по годовому циклу релизов Django

Django в этом году отметил 20-летие. За это время текущий график релизов доказал свою эффективность, но возникают вопросы:

☹️ Номера версий мало что говорят. Видя Django 2.2, сложно понять, когда он вышел и насколько устарел.
☹️ Версии выглядят как семантические (x.0), но на деле не содержат серьёзных изменений. Например, Django 6.0 почти не отличается от 5.2 LTS.

Проблемы текущего цикла:
— Поддержка старых LTS-версий затрудняет обновления Python и создаёт нагрузку на CI.
— Разработчикам сторонних пакетов приходится поддерживать старые версии дольше, чем хотелось бы.
— Большая часть пользователей долго остаётся на неподдерживаемых версиях.

Решение — годовой цикл релизов:
✔️ Один крупный релиз Django в год, вместо одного каждые 8 месяцев.
✔️ Использование календарного версионирования: первая цифра — год, вторая — номер релиза.
✔️ Пример: Django 2028.1 — первый релиз серии, 2028.2 — следующий.
✔️ Каждый релиз получает 1 год исправлений багов и 2 года безопасности, то есть каждая версия будет фактически LTS.
✔️ Поддержка только актуальных версий Python (или плюс последняя «жёлтая»), что снижает нагрузку на CI и синхронизирует EOL Django с EOL Python.

Преимущества:
— Прозрачный и предсказуемый график релизов.
— Облегчённое обновление для компаний и пользователей.
— Каждая версия получает долгосрочную поддержку и безопасность.
— Возможность смелых изменений API без потери стабильности, особенно с инструментом django-upgrade для автоматических обновлений кода.

📌 Итог:
Предлагается внедрить годовой цикл релизов начиная с Django 7.0, с предсказуемой поддержкой Python и LTS для каждого релиза. Это улучшит обновляемость, снизит нагрузку на разработчиков и повысит долю пользователей на поддерживаемых версиях.

Что думаете?

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

#буст

🧠 10 ключевых структур данных, которые мы используем каждый день

— List — лента в Twitter
— Stack — undo/redo в текстовом редакторе
— Queue — очередь печати или событий в игре
— Hash table — кэширование данных
— Array — численные операции и линейная алгебра
— Heap — планирование задач
— Tree — структура HTML-документа или AI-решения
— Suffix tree — поиск подстрок в тексте
— Graph — социальные связи и поиск пути
— R-tree — поиск ближайших соседей
— Vertex buffer — передача данных на GPU для рендеринга

💡 Какие ещё важные структуры данных стоит добавить в этот список?

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

#буст

🧠 Создаём граф знаний из документов с LLM

CocoIndex — инструмент для построения и обновления графов знаний в реальном времени.
Он использует LLM для извлечения связей между концептами в документах и автоматического построения графа:

➡️ Связи между субъектами и объектами — CocoIndex supports Incremental Processing
➡️ Упоминания сущностей в тексте — core/basics.mdx mentions CocoIndex and Incremental Processing

➡️ Подходит для динамических баз знаний, документации и исследовательских проектов.

📱 GitHub
🎞 Видео-туториал
➡️ Статья

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

#буст