Команда Python for Devs подготовила перевод статьи о ключевых изменениях в Python 3.14. Автор разбирает релиз через призму внутреннего устройства интерпретатора и производительности: свободная многопоточность, конкурентные интерпретаторы, удалённая отладка, инкрементальная сборка мусора и новый Tail Calling интерпретатор.
В этой статье будет рассказано о популярных метриках для NLP-задач: классификации текста, NER и кластеризации. Рассказ будет сопровождаться визуализацией, примерами и кодом на Python.
Steam — одна из крупнейших платформ цифровой дистрибуции игр, и одновременно огромный источник данных: каталоги игр, отзывы, достижения, ценовые метрики, активность игроков, региональные различия и многое другое. Однако прямого доступа к агрегированным данным у исследователей нет — их необходимо собирать вручную через Steam Web API и сторонние сервисы.
В этом проекте мы разработали полноценный программный комплекс для автоматизированного сбора, хранения и анализа данных Steam. Построили двухуровневую архитектуру хранилища, реализовали оркестрацию чанков, разработали пайплайны работы с API и конфигурацию параллельного масштабирования. На основе собранных данных сформирован датасет объёмом десятки тысяч игр и сотни тысяч пользователей — и проведён базовый аналитический обзор рынка.
Всем привет!
За последние пару лет компания Astral буквально разрывает Python-мир своими инструментами. Даже если вы не слышали это имя напрямую, с большой вероятностью вы уже пользовались их продуктами — ruff или uv.
И это не преувеличение. И ruff, и uv сегодня фактически стали стандартом индустрии. Например, в свежем релизе PyCharm 2025.3 при создании нового проекта по умолчанию инициализируется именно окружение uv, а не привычный venv. Для open source-проекта — это очень серьёзный показатель доверия со стороны экосистемы.
Открытый исходный код и массовое принятие инструментов Python-разработчиками дали Astral тот самый «кредит доверия», который компания, судя по всему, пока что уверенно оправдывает.
И вот буквально на днях Astral объявили, что их новый «революционный» тайп-чекер ty переходит в стадию бета-тестирования. А если учитывать, что и uv, и ruff формально тоже всё ещё находятся в бете, то можно считать, что ty уже фактически вышел в релиз. Собственно, о нём и поговорим дальше.
Если вам интересны подобные материалы — подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков и полезными инструментами. А прямо сейчас у нас ещё и проходит новогодний розыгрыш.
Это третья часть моей мини‑саги про вайбкодинг, LLM и здравый смысл в разработке. В первой статье я уже рассказывал, как по совету ИИ едва не снёс себе БД, а во второй — разбирался, страшен ли этот самый вайбкодинг или это просто инерция мышления перед лицом прогресса.
Сегодня я хочу поговорить о «священном граале» текущего AI-хайпа — полной автономности кодинг-агентов. О том, почему вера в то, что нейросеть «сама всё напишет, пока я пью кофе», — это опасное заблуждение, которое лишь усиливает скепсис профильного сообщества.
Python часто начинают осваивать с простых скриптов и функций. Пока задачи простые, этого достаточно. Но когда в коде появляются сущности, например, пользователи, книги или машины, взаимодействие с ними строится по другим принципам.
Для этого в Python используют классы. С их помощью описывают, какие данные есть у таких сущностей (объектов) и что с ними можно делать. Это и есть объектно-ориентированный подход — программа строится вокруг объектов и их взаимодействия.
В этой статье мы разберём основы работы с классами и объектами в Python: как они устроены, как их использовать и какие концепции вокруг них стоит знать, даже если вы пока не планируете углубляться в архитектуру.
Осенью я начала готовиться к будущему выходу из декретного отпуска, купив курс Яндекс.Практикума «Продвинутый Go-разработчик». Сейчас я еще в процессе прохождения курса и недавно сдала первый дипломный проект, но уже сейчас могу сказать, что разработка ПО вышла на другой уровень за время моего отпуска длиной почти в 2 года. В разработке сервисов появилось много приятных фишек, которые мне нужно освоить. В данной статье я хочу описать то, какие изменения я уже заметила в разработке ПО и что я уже смогла почерпнуть из курса практикума.
Начать хочется с максимально актуальной темы — это использование нейронных сетей. Без них в современном мире разработки(и не только) теперь никуда. Когда я уходила в декретный отпуск, то только малая часть разработчиков активно использовала их, сейчас это повсеместно. Вот пару примеров того, как они уже облегчают нам жизнь.
Недавно я заметил такую штуку: знакомые фрилансеры и маленькие студии разработки частенько теряют заказы, да и организовано у них всё так себе. Сообщения находятся то в одном сайте, то в другом, программисты в Discord сервере, заказчики и прогрев в Telegram, но при этом ещё надо в какую‑то CRM заходить и там ещё что‑то тыкать щёлкать. В общем — мест много, запутанно всё и не удобно.
Подумал: «А что если сделать CRM, которая работает ИЗ телеграма?» Клиент отправляет заказ боту, менеджеры видят в веб‑интерфейсе, программисты предлагают цены, все получают уведомления. Всего два места, но при этом заказчику вообще не надо об этом думать, он в телеграмме, там где уже зарегистрирован. Красиво же?
И я начал.
Всем привет, меня зовут Максим Шаланкин, Machine Learning Team Lead в команде финтеха Big Data MWS. Внутренняя аналитика в финтехе живет в режиме постоянной гонки: новые клиенты приходят, ведут себя по‑разному, а бизнесу нужно быстро понимать, чем группы с разными сценариями отличаются друг от друга. При этом значительная часть работы аналитика — это однотипное сравнение когорт и поиски закономерностей в табличках и графиках. Фоновый LLM‑агент, который умеет сам поднимать данные, запускать статистические проверки и возвращать готовые инсайты, заметно сокращает путь от данных до решения.
Под катом — разбор, как устроен такой background‑агент для анализа активности новых клиентов, на чем он основан, как мы минимизируем галлюцинации и почему выбрали архитектуру, похожую на Claude Skills, а не идем в сторону MCP‑подхода.
На дворе 2025 год. Мы привыкли к f-строкам и тайп-хинтингу, но всё ещё тащим в продакшен привычки из Python 3.6.
Вы знали, что блок else в цикле for выполняется вовсе не тогда, когда «цикл не сработал», а наоборот? А что громоздкий try-except pass для игнорирования ошибок — это антипаттерн, который заменяется одной элегантной строкой из стандартной библиотеки?
В статье — топ-5 прагматичных фич (от match/case с гардами до itertools.batched), которые позволяют писать декларативный код и выбрасывать лишние if и флаги. Никакой воды, только примеры «Было / Стало».
От монолита к модулям: строим масштабируемую архитектуру AI-агентов с FastMCP и LangChain
Год бума AI-агентов показал: самая большая проблема — не галлюцинации, а архитектура. Когда инструментов много, а агенты распухают, копипаста и сложность тестирования убивают скорость разработки.
Хотя экосистема LLM в основном ориентирована на Python, мы нашли Go исключительно подходящим для производственных развертываний. Наша инфраструктура на базе Go обрабатывает миллионы ежемесячных запросов LLM с минимальной настройкой производительности. Помимо хорошо документированных преимуществ Go (см. отличное изложение Роба Пайка о преимуществах Go), три возможности оказались особенно ценными для нагрузок LLM: статическая проверка типов для обработки выходных данных модели, горутины для управления параллельными вызовами API и интерфейсы для построения составных конвейеров ответов. Вот как мы реализовали каждую из них в нашем производственном стеке.
Эта статья — не про "как я выучил Python за неделю", а про реальный инженерный путь: от первых экспериментов с ChatGPT API до production-ready систем, которые обрабатывают тысячи запросов в день. Я расскажу про конкретные проекты, инструменты, пайплайны и главное — про ошибки, которые стоили мне времени и денег.
С помощью предобученной мультиязычной модели LaBSE и методов снижения размерности выяснил, что поэмы Лермонтова и Симонова, несмотря на столетнюю дистанцию, семантически близки. Подтвердил гипотезу, что русская патриотическая поэзия сохраняет устойчивое смысловое ядро, даже когда меняется стиль и идеология.
Привет, Хабр! Cегодня я хочу поговорить о самом непонятном и переоцененном термине в мире архитектуры — Domain-Driven Design (DDD). Я объясню его так, чтобы стало понятно даже джуну, и покажу на реальных примерах, чем он отличается от других подходов.
В своей прошлой статье я рассказывал, как продвинутая LLM для написания кода может упустить очевидные вещи и привести к потере данных. Та история была скорее о техническом курьезе, который может случиться при бездумной вере в возможности нейросети.
Сегодня я хочу поговорить о самом вайбкодинге как о явлении, вызывающем бурю эмоций в IT-сообществе. Этот термин, придуманный и популяризированный Андреем Карпатым в начале 2025 года, быстро стал нарицательным. Для одних это будущее, для других — синоним «говнокода». Но так ли страшен вайбкодинг, как его малюют?
TRIZ Insight — агент‑решатель противоречий. Он берёт задачу, прогоняет её через формальный ТРИЗ‑скелет и LLM, а на выходе даёт конкретный план действий с ролями, шагами и метриками успеха. Подходит для личных и бизнесовых задач.
Представьте: вы ведете автомобиль, а на приборной панели нет ни спидометра, ни датчика топлива, ни каких-либо показателей вообще. Ни-че-го. В принципе ехать можно, но вы не знаете, какая у вас скорость, сколько бензина и есть ли с авто какие-то проблемы. Примерно так выглядит работа с LLM-приложением без инструментов мониторинга: система вроде бы и функционирует, но о ее внутреннем состоянии можно только догадываться.
Меня зовут Александр Сесоров, я работаю инженером по тестированию в YADRO. Занимаюсь задачами автоматизации оценки производительности, точности и эффективности моделей на различных конфигурациях. Сегодня проведу краткий экскурс в инструментарий Langfuse и на примерах из практики покажу, как превратить оценку качества LLM-приложения из гадания в систематизированный и прозрачный сбор метрик на всех этапах.
Начинаю цикл статей о создании 2д игры-платформера, на основе документации библиотеки arcade. Вначале буду показывать самые простые этапы, могу данные этапы преобразовывать или даже удалять, в итоге будут написаны классы (это ООП) и создан exe файл.
Этапы разработки платформера
1. Придумать идею игры
2. Показать простые примеры для новичков в программировании (создание окна и главного героя, элементов игры, подготовка файлов и папок)
3. Реализация механики персонажа
· Загрузка текстур и спрайтов персонажа
· Реализация движения, прыжков и физики
· Использование физического движка (PhysicsEnginePlatformer или Pymunk)
4. Создание карты и тайлов
· Используйте Tiled Map Editor для создания уровней
· Сохраните карту в той же директории, что и код
· Добавьте тайловые изображения в подпапку
5. Добавление игровых элементов
· Коллизии со стенами и платформами
· Сбор предметов, монеты
· Враги и взаимодействие с ними
· Анимация персонажа
6. Система сохранения
· Реализация сохранения прогресса игры
· Сохранение уровня, здоровья, предметов
7. Уровни игры
8. Меню игры
9. Экспорт в EXE файл
Финансовые рынки редко движутся изолированно. Криптовалюты реагируют на фондовые индексы, золото реагирует на макроэкономику, а внутри крипторынка движение биткоина задаёт направление для альткоинов.
Гипотеза проекта:
Если агрегировать данные по разным классам активов (крипто, акции, золото), измерить их волатильность, тренд и взаимную корреляцию, можно получить осмысленную вероятностную оценку того, каким будет рынок в ближайшие 24 часа: рост, падение или консолидация.
