Мем дня: на сайте AI World Clocks девять ИИ-моделей каждую минуту получают простейшее задание — сделать обычные аналоговые часы на HTML и CSS.

Казалось бы, что может быть сложного?)

🤔 Python 3.14 без GIL: что это значит для веб-разработки?

Последние месяцы в новостях про Python много говорили о скорости: сравнивали 3.14 с 3.13, спорили о бенчмарках, радовались снижению оверхеда. Но почти нигде не было упора на веб-разработку.

Новая статья, которую мы перевели, закрывает этот пробел — и делает это на реальных ASGI и WSGI-приложениях.

Если коротко по фактам: в Python 3.14 free-threaded режим перестал быть экспериментом и почти догнал «обычный» интерпретатор по оптимизациям — провал в производительности сократился с ~35% до 5–10%. Но в вебе абсолютная скорость чистого Python — не главное. Здесь решает конкурентность, а она упиралась в GIL десятилетиями. Масштабирование через воркеры, гигабайты памяти на процессы — всё это было больше про обход ограничений, чем про реальные потребности приложений.

Практические тесты это подтверждают. В ASGI-приложениях free-threaded версия почти не уступает по I/O, зато заметно экономит память: можно держать больше сервисов на одной машине, упираясь в CPU, а не в RAM. В WSGI-сценариях картина смешанная: огромный выигрыш на CPU-нагруженных эндпоинтах, но и заметный рост потребления памяти — возможно, вопрос того, как серверы и GC адаптируются к новой модели исполнения.

Главная мысль: free-threaded Python не столько «ускоряет веб», сколько упрощает и стабилизирует его. Меньше магии с потоками и процессами, меньше компромиссов ради GIL, более предсказуемое масштабирование. Для большинства веб-сервисов это уже сейчас выглядит практичным улучшением, а не экспериментальной фичей.

@python_for_devs

🐍 Почему Python — вообще не идеален для data science — и что с этим не так

Перевели любопытную статью: Клаус Вилке объясняет, почему Python, несмотря на статус языка №1 в data science, на самом деле делает многие базовые вещи... неудобными. И дело не в студентах, не в навыках и даже не в привычках — проблема глубже.

Автор двадцать лет руководит биоинформатической лабораторией. И вот типичный сценарий: студент показывает анализ, Клаус просит «чуть поменять график» — violin вместо boxplot, heatmap вместо line plot, плотность вместо гистограммы.

В R это 2–3 строки. В случае с Python студенты обычно отвечают:

Окей, дайте немного времени, я вернусь

И речь о вполне сильных ребятах.

Даже опытные дата-сайентисты, которые знают pandas, NumPy и matplotlib вдоль и поперёк, постоянно тонут в синтаксических костылях: лишние кавычки, лишние скобки, лишние манипуляции. То, что в R выражается естественным языком, Python требует «ручной сборки»: группировки вручную, столбцы в кавычках, агрегаты в виде кортежей, а иногда и возвращение в мир списков, циклов и словарей — просто чтобы сделать что-то концептуально простое.

Да, pandas вроде бы закрывает большинство задач. Но стоит анализу выйти за рамки «группировка + среднее» — и инструменты начинают работать против пользователя. Автор честно признаёт: в Python слишком легко сорваться с уровня анализа на уровень рутинной возни.

Вилке формулирует простой критерий: хороший язык для data science — это тот, где вы описываете намерение, а не механику. «Хочу взять пингвинов, убрать пропуски, сгруппировать по виду и острову, посчитать статистики». На R это почти копирует естественную фразу. В Python — похожие конструкции есть, но гораздо быстрее оказываешься среди индексов, типов и мелкой логики.

📚 Читайте и комментарийте на Хабр.

@python_for_devs

🤩 Django 6.0 получил встроенные фоновые задачи — но это только начало пути

Django наконец добавил единый API для фоновых задач — модуль django.tasks. Это важное изменение: раньше у каждого решения (Celery, Huey, RQ и др.) были свои декораторы, свои подходы. Теперь есть общий стандарт, на который можно опираться.

Но есть нюанс: в Django 6.0 нет воркеров. Совсем. Фреймворк умеет ставить задачи в очередь, но не умеет их выполнять — этим по-прежнему должны заниматься внешние процессы. Из коробки есть только ImmediateBackend, который запускает задачу тут же, и DummyBackend, который не делает ничего.

Де-факто, это первый шаг большого пути, цель которого — не заменить Celery, а дать унифицированное ядро, на котором будут строиться адаптеры, бекенды и новые Open source-решения. Именно поэтому в Django 6.0 API простое и намеренно ограниченное: никаких ретраев, оркестрации, бэкоффов или цепочек задач.

@python_for_devs

🚀 Вышел Django 6.0

Фреймворк получил встроенные Background Tasks — лёгкий способ запускать фоновые процессы без Celery и тяжёлой инфраструктуры. Про них мы как раз недавно рассказывали.

Появились Template Partials — нормальные переиспользуемые куски шаблонов вместо хака с наследованием. Вёрстка сложных страниц станет куда чище.

На стороне безопасности — нативный CSP, наконец-то без сторонних пакетов. Плюс обновлённый Email API на базе EmailMessage.

С релизом 6.0 ветки 5.2 и 5.1 ушли с основной поддержки — для всех старых проектов самое время планировать апдейт.

@python_for_devs

⚡️ JetBrains представила Air: новую агентную IDE

Компания выпустила Air — ADE (Agentic Development Environment), ориентированную на гибридную работу «разработчик + ИИ-агенты».

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

Air пока доступен в превью и работает только с одним агентом — Claude Agent, причём для использования требуется активная подписка Anthropic.

Версии для Windows и Linux обещают в 2026 году — сейчас приложение доступно только на macOS.

Сайт | Документация | Анонс в X | Анонс на Habr

@ai_for_devs

⚡️ Вышел PyCharm 2025.3

В новом релизе JetBrains объединили пользователей Community с основным дистрибутивом, усилили инструменты для Data Science и удалённой разработки, а также расширили поддержку современных LSP-сервисов.

Коротко — самое важное:

— Community Edition переехал в единый дистрибутив PyCharm, вместе с полной поддержкой Jupyter.
— Полная работа с Jupyter-ноутбуками при удалённой разработке (Pro): интерактивные таблицы, графики, Variables, Data View.
— uv теперь менеджер окружений по умолчанию — быстрый старт и автоматическая установка нужной версии Python.
— Упреждающий анализ данных для pandas: пропуски, выбросы, дубликаты, корреляции + Fix with AI.
— Поддержка Ruff, Pyrefly, Pyright и ty через LSP — форматирование, типы, выводимые аннотации прямо в коде.
— Новое окно Process Output: вся диагностика команд IDE в одном месте, без модальных поп-апов.
— Новая тема интерфейса Islands по умолчанию.
— Обновлённый немодальный Welcome-экран с быстрым стартом проектов.

📚 Читайте и комментируйте на Хабр.

@python_for_devs

⚔️ Pyrefly & ty — два новых Rust-анализатора типов для Python

Оба работают инкрементально, используют Ruff для AST и показывают отличную скорость. В бенчмарках на PyTorch и pyrefly и ty оказываются в 10–20 раз быстрее классических анализаторов, причём ty в тестах стабильно обгоняет pyrefly ещё в 2–3 раза.

Pyrefly идёт по пути агрессивного вывода типов — пытается вывести максимум даже из полностью неаннотированного кода и за счёт этого ловит тонкие ошибки, которые mypy и pyright пропускают. Минус такой стратегии — иногда появляются ошибки там, где Python-программа вообще-то работает. Зато дженерики, перегрузки и сложные контейнеры pyrefly уже сейчас обрабатывает весьма уверенно.

ty, наоборот, придерживается принципа gradual guarantee: если код рабочий, анализатор не должен превращать его в «кладбище ошибок». Он реже делает жёсткие выводы, выдаёт значительно более читабельные ошибки и вводит крутые новые возможности вроде intersection types и negation types — единственная реализация таких типов в Python-анализаторах на сегодня.

Пощупать можно уже сейчас: у pyrefly есть sandbox, у ty — playground.

@python_for_devs

🎓 Нашли бесплатный курс Introduction to LangChain (Python)

Внутри:
— 28 уроков
— 1.5+ часа видео
— практические проекты

Для тех, кто хочет уверенно войти в агентные системы: https://academy.langchain.com/courses/foundation-introduction-to-langchain-python

@python_for_devs

🎥 Manim — математические анимации уровня 3Blue1Brown на Python

Статичные формулы и графики плохо объясняют сложные идеи. Manim решает эту проблему, позволяя создавать математические анимации кодом — в том самом стиле, который сделал 3Blue1Brown эталоном визуальных объяснений.

Через Python можно управлять всем: фигурами, LaTeX-формулами, их пошаговыми преобразованиями, движением камеры и траекториями. Manim особенно хорош там, где важно показать процесс рассуждения, а не просто финальный результат — выводы формул, геометрию, графики функций.

📚 Подробнее в нашей новой статье на Хабре.

@python_for_devs

⚡️ Опубликована предварительная страница What’s new in Python 3.15

До релиза ещё далеко, документ в статусе draft и будет заметно меняться, но часть ключевых направлений уже видна.

Коротко, что уже заявлено:

— PEP 799: отдельный пакет для профилирования и организации profiling-инструментов
— PEP 799: Tachyon — высокочастотный статистический sampling-профайлер
— PEP 686: UTF-8 становится кодировкой по умолчанию
— PEP 782: новый C API PyBytesWriter для создания bytes-объектов
— Существенные обновления JIT-компилятора
— Улучшенные сообщения об ошибках

Полный список изменений и детали в официальном changelog.

@python_for_devs

🤔 Почему Python иногда «течёт» по памяти — и при чём тут weakref

В Python управление памятью в основном держится на подсчёте ссылок: объект живёт, пока на него есть хотя бы одна сильная ссылка. В большинстве случаев это работает прозрачно, но есть коварные сценарии — циклические ссылки, кэши и списки подписчиков — где объекты начинают жить дольше, чем нужно.

Да, в CPython есть GC, который умеет разрывать циклы. Но он запускается не сразу, работает не бесплатно и не спасает от логических утечек, когда вы сами «держите» объект через кэш или реестр.

Здесь на сцену выходят слабые ссылки (weakref). Они позволяют ссылаться на объект, не продлевая его жизнь. Как только пропадают сильные ссылки — объект удаляется, даже если на него кто-то «смотрит» через weakref.

На практике это даёт несколько очень полезных паттернов:
— автоочищающиеся кэши через WeakValueDictionary
— реестры и singleton-подобные структуры, которые не держат объекты насильно
— списки подписчиков (`WeakSet`), где не нужно вручную отписывать «умершие» объекты
— аккуратную работу с долгоживущими менеджерами и короткоживущими сущностями

Отдельный бонус — callbacks у weakref: можно повесить логику очистки, которая сработает ровно в момент сборки объекта.

📚 Подробнее в нашей новой статье на Хабре.

@python_for_devs