Hacker News Digest

Python 3.14 представляет значительный прорыв для многопоточного Python, так как его "free-threaded" вариант достиг фазы II и больше не считается экспериментальным. Производительность улучшилась с 35% штрафом до всего 5-10%, а реализация теперь использует адаптивный интерпретатор без обходных решений из Python 3.13. Автор, разработчик веб-фреймворка и веб-сервера, провел сравнительное тестирование для веб-приложений, так как большинство существующих сервисов являются I/O-bound, а многопоточность критически важна.

Для тестирования были созданы ASGI-приложение на FastAPI и WSGI-приложение на Flask, каждый с двумя конечными точками: генератором JSON и имитацией I/O-операции с задержкой 10мс. Использовался сервер Granian, который работает с потоками вместо процессов, и инструмент rewrk для нагрузки. Цель - определить, можно ли наконец отказаться от гигабайтов памяти, тратимых на multiprocessing для параллельной обработки запросов в веб-сервисах.

• Появление free-threading в 3.13-3.14 сделало C-расширения, не обновлённые под free-threading, небезопасными и требует их обновления.
• Сообщество обсуждает, что отсутствие GIL в 3.14 может привести к тому, что старые библиотеки будут вести себя непредсказуемо, и предлагает, чтобы CPython поставлял инструмент для сканирования и обновления кода.
• Участники обсуждают, что влияние free-threading на производительность варьируется от «ничего не изменилось» до «значительно лучше» в зависимости от IO vs CPU bound кода, и что влияние на реальные приложения будет варьироваться от «ничего» до «значительно лучше».

Разработчики представили Hyperflask — новый фреймворк для Python, который объединяет множество инструментов в единую экосистему для ускорения разработки веб-приложений. Основная идея в том, чтобы избавить разработчиков от необходимости самостоятельно подбирать и настраивать различные технологии, которые часто требуются в проектах.

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

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

• Единая структура проекта: стандартизированная организация кода, что ускоряет onboarding новых разработчиков и упрощает поддержку.
• Готовые решения для типовых задач: аутентификация, отправка email, обработка файлов, фоновые задачи — всё доступно "из коробки".
• Гибридный рендеринг: статические страницы генерируются на сервере для скорости, но при необходимости могут динамически обновляться через HTMX.
• Оптимизация под SEO: серверный рендеринг гарантирует, что контент индексируется поисковыми системами.

Разработчики подчеркивают, что Hyperflask не просто набор инструментов, а целостная экосистема, где все части глубоко интегрированы. Это позволяет избежать типичных проблем, когда отдельные библиотеки, будучи собранными вручную, конфликтуют друг с другом.

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

Для сообщества это может быть значимым, поскольку экосистема Python долгое время не имела полноценного аналога популярным JavaScript-фреймворкам вроде Next.js. Hyperflask, хоть и молодой проект, показывает важный шаг в этом направлении.

• Обсуждение в основном вращается вокруг сравнения Flask/HTMX-стека с альтернативами (FastAPI, Django, Litestar, FastHTML), где критика касается производительности, архитектуры и "state of the art" в 2025 году.
• Участники спорят о целесообразности смешивания шаблонов и логики в одном файле, о том, насколько это упрощает или усложняет разработку, и о том, как это сказывается на тестируемости и сопровождении кода.
• Ряд комментаторов поднимает вопрос о том, что выбор Flask в 2025 году может быть устарел, особенно если учесть отсутствие встроенной поддержки async/await, и сравнивает его с FastAPI или Litestar.
• Некоторые участники высказывают мнение, что вместо того, чтобы изобретать еще один каркас, было бы лучше взять существующий и внедрить в него улучшенную документацию, инструменты и лучшие практики.

Microdot: крошечный веб-фреймворк для всего

Мигель Гринберг, автор Flask Mega-Tutorial, представил Microdot — мини-фреймворк, работающий и на CPython, и на MicroPython: от IoT до облаков.

Зачем?
Зимой 2018-го в Ирландии Мигель столкнулся с «умным» отоплением, которое погрешало на ±3 °C. Он отключил термостаты, поставил на каждый этаж плату с MicroPython и датчиком (±0,5 °C) и сам включал/выключал нагрев.
Чтобы с дивана видеть температуру и статус, ему нужен был веб-сервер, но Flask и Bottle на MicroPython не лезли. Поэтому он написал Microdot — «Flask в миниатюре».

Фишки

• одна папка, ~1500 строк, нулевые зависимости
• маршруты, шаблоны, cookies, WebSocket, SSE, CORS, SSL, Basic/Digest-аутентификация, тест-клиент
• копирует API Flask: @app.route, request.args, jsonify, abort, before_request
• работает на ESP32, Raspberry Pi Pico, обычных серверах
• ставится pip install microdot (CPython) или mip install microdot (MicroPython)
• опциональные плагины: microdot-session, microdot-cors, microdot-websocket, microdot-jinja, microdot-asyncio

Код

from microdot import Microdot
app = Microdot()

@app.route('/')
async def index(req):
    return {'temp': 22.5, 'heating': False}

app.run(port=80, debug=True)

Размер
ESP32: 70 КБ свободной ОЗУ остаётся после загрузки MicroPython + Microdot + приложение.
CPython: ~1 МБ venv.

Кому

• хобби-IoT: датчики, реле, роботы
• встраиваемые системы: промышленные контроллеры, автономные датчики
• прототипы: быстро поднять REST, потом перейти на Flask/FastAPI
• обучение: Flask-разработчики учатся за пять минут

Где
GitHub: github.com/miguelgrinberg/microdot
Документация: microdot.readthedocs.io
PyPI: pip install microdot

• Microdot — это 765-строковый Python-фреймворк, который работает и на CPython, и на MicroPython; предназначен для веб-серверов на IoT-устройствах (ESP32 и др.).
• Автор @miguelgrinberg подтвердил, что расширения (шаблоны, сессии) опциональны и почти не требуют зависимостей; версия 2 внесла ломающие изменения.
• Комментаторы спорят о слове «impossibly small»: кто-то считает 765 строк нормальным минимумом, кто-то — перебором; сравнивают с Bottle, Rails 0.x и FW/1.
• Пользователи делятся опытом: SSE + htmx для живых GPIO-индикаторов, бенчмарки RPS, проекты термостатов и садовых сенсоров.
• Упоминаются альтернативы (TurboLua, BirSaat) и вопрос: «почему бы не написать это на C?»

• Async в Python уже 10 лет, но до сих пор не стал мейнстримом.
• Причины:
  • ошибки «забыл await», трудно отлаживать;
  • GIL приучил не думать о параллелизме;
  • польза только при I/O-задачах, CPU-нагрузка не ускоряется;
  • фреймворки не догнали: Django ORM всё ещё синхронен, Flask тоже.
• Классический кейс — HTTP-запросы: стартуем сотни корутин, ждём ответов, не блокируем интерпретатор.
• Но дисковый I/O, CPU-задачи и другие сценарии не так выигрывают.
• Вывод: чтобы новые фичи 3.14 (free-threading, sub-interpreters) не повторили судьбу async, нужно:
  • чётко объяснять, какие задачи они решают;
  • давать простые API и инструменты отладки;
  • не ждать, пока экосистема «догонит», а сразу внедрять в популярные библиотеки.

• Async в Python пришёл «слишком поздно»: к моменту появления asyncio большинство уже решали задачи I/O через forking, multiprocessing или сторонние библиотеки.
• «Цветные функции» и необходимость переписывать весь код ради async делают его «заразным» и несовместимым с существующими синхронными библиотеками.
• Сложная семантика (event-loop, await, cancellation-исключения), плохая документация и отсутствие понятных best-practice усложняют отладку и поддержку.
• Для большинства задач Python-разработчика async не критичен: WSGI/WSGI-совместимые решения, Celery, Kafka и простое горизонтальное масштабирование покрывают потребности.
• Альтернативы (trio, anyio, gevent) и другие языки (Go, Elixir) предлагают более простые модели конкурентности без «раскрашенных» функций.

PlutoPrint — библиотека Python для генерации PDF и изображений из HTML, работает на базе PlutoBook.
Установка: pip install plutoprint.

Основные возможности

• HTML → PDF/PNG/JPEG — одна строка кода.
• CSS/JS — полная поддержка современных стандартов.
• Шаблоны — Jinja2, Django, Flask и др.
• Пакетная обработка — асинхронный режим.
• Docker-образ для быстрого деплоя.

Быстрый старт

from plutoprint import PlutoPrint

pp = PlutoPrint()
pp.html_to_pdf("report.html", "report.pdf")

Параметры

• format: pdf, png, jpeg
• width/height, orientation, margin, header/footer, dpi

Примеры

• Отчёты, чеки, инвойсы, почтовые этикетки, скриншоты страниц.

Лицензия

MIT.

• Пользователи сравнивают PlutoPrint с WeasyPrint, Puppeteer и Typst: новый движок на C++ обещает быть быстрее и легче по памяти, но покрывает не весь CSS.
• Рекомендуют прогнать тесты с print-css.rocks и проверить прод-качество (проблемы с thead, page-break-inside и т.д.).
• Puppeteer даёт полную поддержку веб-платформы, но требует Chromium и много RAM, особенно для 200-500-страничных PDF.
• Есть вопросы по flexbox, SVG, оглавлению, поддержке Markdown и крэшу на macOS.
• Несколько человек рассматривают PlutoPrint как замену wkhtmltopdf и fpdf, автор открыт к спонсорству.