🐍 Почему 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

⚡️ DuckDB разрушает мифы: 1 ТБ данных — за секунды, без Spark

Принято считать, что терабайты аналитики – это всегда Spark, кластеры и сложная инфраструктура. Но свежий бенчмарк показывает обратное: DuckDB спокойно агрегирует 1 ТБ данных на одном движке — и делает это менее чем за 30 секунд.

Запрос самый обычный: группировка по дате, count(*) и sum(value). Никаких синтетических трюков. Локально на MacBook M2 Pro — около 1,5 минуты. В облачном MotherDuck — в среднем ~17 секунд.

Финальный буст даёт сортировка данных при загрузке. Благодаря zonemap-индексам одна из итераций укладывается меньше чем в 10 секунд. Просто потому что данные лежат «правильно».

Полный разбор, бенчмарки и код — читайте целиком на Хабре.

🔥 Anthropic инвестируют $1.5 млн в Python — и делают ставку на безопасность open source

Anthropic объявили о двухлетнем партнёрстве с Python Software Foundation и инвестируют $1.5 млн в развитие Python-экосистемы. Ключевой фокус — безопасность цепочки поставок и защита PyPI.

Деньги пойдут на конкретные инженерные изменения:

– разработку проактивных инструментов анализа всех пакетов, загружаемых в Python Package Index, вместо текущей в основном реактивной модели
– создание датасета известного malware для анализа поведения и capability-based детекта
– улучшения, которые потенциально можно будет перенести и на другие open source репозитории, не только Python

@python_for_devs

В новой статье разбираем попытку превратить Python в формат распространения уровня «один бинарник»

Идея простая: вместо Docker-образов с интерпретатором и зависимостями компилировать обычные Python-функции в кроссплатформенные исполняемые файлы, которые запускаются вообще без Python.

Работает это следующим образом: Python-код разбирают в AST, строят промежуточное представление, затем "понижают" его до C++ и компилируют под нужную платформу — от серверов до мобилок и WebAssembly.

Интересная часть — оптимизация. Из одной Python-функции генерируют сразу много эквивалентных C++-программ с разными библиотеками, алгоритмами и ускорителями. Все варианты тестируются на реальном железе, собирается телеметрия, и дальше система эмпирически выбирает самый быстрый путь.

LLM используют утилитарно: для генерации и поддержки большого количества C++-операторов под разные библиотеки.

Для пользователя всё сводится к декоратору @compile и CLI.