Python *

Ну, не ваша, хабравчане, а ваша, создатели языков, библиотек, фреймворков итд. Но давайте не забегать вперёд.

Я как-то привык что если что-то ломается или плохо работает, то это я виноват. Это называется «брать ответственность за свои поступки» или, в случае программиста, за свой код, и это считается хорошим делом.

Разумеется, по эго это бьёт иногда больно, и некоторые моменты вспоминать не очень приятно. Самое страшное, что я когда-либо делал — коммитил приватный ключ в публичной репо. Вот написал и мне опять стыдно. Но я осознаю, что это всё я.

Но внезапно я открыл для себя тот факт, что не во всех ошибках моя вина. То есть да, это моя голова думает код, это мои руки печатают этот код, но ошибка идёт не от меня. Ошибка заложена ещё раньше, вообще задолго до меня, а иногда даже задолго до моего рождения.

Сейчас я вам это покажу. Будет интересно, но впереди много боли. Я предупредил.

Аугментация данных — один из самых мощных инструментов улучшения качества моделей машинного обучения. В компьютерном зрении она почти всегда критична: без неё модели быстро переобучаются и плохо обобщаются.

Но на практике её часто используют поверхностно: «добавим флип, поворот и color jitter».

В этой статье разбираем аугментации глубже:
— два режима аугментаций (in-distribution и out-of-distribution)
— почему нереалистичные трансформации могут улучшать обобщающую способность
— когда аугментации начинают вредить
— как строить устойчивый пайплайн аугментаций

Материал основан на ~10 годах практики обучения моделей компьютерного зрения (на работе, при написании научных статей, в ML соревнованиях) и ~7 годах разработки библиотеки Albumentations.

Когда у меня появилась теплица, первым желанием было автоматизировать всё, что можно: контроль температуры, управление вентиляцией, полив, освещение. Готовые решения либо стоят дорого, либо замкнуты в экосистеме одного производителя, либо не дают нужной гибкости. Поэтому я решил создать собственную систему по автоматизации управления процессами в теплице. Также у меня было много бесхозных контроллеров ESP8266/ESP32, которые нужно было куда‑то «пристроить».

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

Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.

Когда разработчики приходят в Python из Java или C++, у них часто случается культурный шок. Они безуспешно ищут модификаторы private или protected и задают логичный вопрос: «А как здесь вообще прятать данные?»

Добро пожаловать в мир, где язык вам доверяет, а Гвидо ван Россум говорит: «Мы здесь все взрослые люди». В новой статье разбираем архитектурный дзен Python:

🔹 Почему двойное подчеркивание (__) — это не аналог private (и как его взломать в одну строчку).
🔹 Почему классические геттеры и сеттеры в Python — это антипаттерн.
🔹 Как элегантно защитить данные с помощью @property, дескрипторов и slots.
Никаких заезженных метафор про пульты от телевизора. Только суровая (и красивая) реальность Python-way.

«Вайбкодинг» ‑ это просто ролевая игра для парней, которые хотят чувствовать себя хакерами, не делая сложной работы, или это мощный инструмент, меняющий процессы даже ML‑инженера? Я думал, что это просто игрушка, пока не попробовал.

Привет, меня зовут Марк, я ML-инженер уже более 4-х лет и за несколько дней я навайбкодил приложение не зная ни языка ни технологий. А еще я навайбкодил кучу техдолга и получил неочевидные трансформации личности.

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

Я бывший фронтенд-разработчик, который уже семь лет работает корпоративным юристом. Устал копировать одни и те же реквизиты в десятки типовых форм. Пробовал автоматизировать через Excel, мечтаю о React-приложении, но в итоге остановился на Python-скрипте, который штампует документы за секунды.

Рассказываю про путь от идеи до реализации и почему для небольших юридических команд до сих пор нет нормальных инструментов.

Мне 34, из них больше десяти лет я в коммерческой разработке. И примерно столько же я женат. Каждый год 7 марта я ловил себя на мысли, что стою в торговом центре с пустым взглядом, пытаясь угадать с подарком. В этом году я решил подойти к проблеме не как муж в панике, а как инженер.

Я прочитал книгу Гэри Чепмена «Пять языков любви», поймал пару инсайтов и за 5 вечеров написал сервис-переводчик для пар. Внутри: Flask, Vanilla JS (да, в 2025 году, и я объясню почему), DeepSeek API для генерации карточек в стиле «Love is…» и алгоритм матчинга, который понимает мою жену лучше, чем я за 10 лет брака. Под катом — история о том, как код помогает чинить баги в коммуникации.

Менеджер памяти CPython — одна из тех частей интерпретатора, о которых часто слышат, но редко понимают, как они устроены на самом деле.

Каждый объект Python — число, строка, список или словарь — должен где-то жить в памяти. Интерпретатор создаёт миллионы таких объектов и так же быстро их уничтожает. Чтобы это работало эффективно, CPython использует собственный аллокатор памяти и несколько уровней оптимизации.

В этой статье мы пошагово спроектируем менеджер памяти CPython, начиная с самой простой модели и постепенно приходя к архитектуре:

Arena → Pool → Block → Reference Counting → Cycle GC

В Python хватает инструментов для работы с временными рядами, но обычно приходится жонглировать тремя-четырьмя пакетами с разными API. Darts — библиотека, которая собирает всё в одном месте: статистические модели, градиентный бустинг, нейросети — и работает по знакомой схеме fit() / predict(). Сегодня разберём её подробно: что умеет, где удобна, как использовать в задачах.

По данным Stack Overflow Developer Survey, pandas — самая ищемая Python-библиотека. Разбираем четыре топовых вопроса: итерация по строкам, переименование колонок, удаление NaN и фильтрация. Для каждого — несколько способов с бенчмарком и рекомендацией «как надо делать в 2026».

Привет, Хабр! На фоне ажиотажа вокруг нейросетей все чаще встает вполне приземленный вопрос — сколько стоит содержать собственную LLM.

Современные ИИ-агенты уровня Claude, ChatGPT и DeepSeek уже давно перестали быть «чатами для развлечения». Это сложные системы, которые перед тем как выдать ответ, тратят десятки тысяч токенов на внутренние рассуждения, вызывают внешние функции, взаимодействуют с MCP-серверами и даже работают напрямую с интерфейсом ОС.

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

В статье я покажу практичный компромисс: как развернуть собственную облачную LLM, которая укладывается в 16 ГБ видеопамяти, поддерживает инструменты и вызов функций, интегрируется с MCP-серверами и может использоваться как полноценный API-сервис для бэкенд-задач. 

PyPI — централизованный каталог Python-пакетов. Сегодня в нем более 865 тысяч проектов общим весом 36 терабайт.

PyPI создал Ричард Джонс. В октябре 2002-го, в электричке, по дороге на работу в Мельбурн.

Сегодня расскажу о модели, которую мы построили для оценки реального эффекта промокодов. Главные вопросы: кому, какой, и зачем мы выдаем промокод. Спойлер: ответ нас удивил. И именно этот ответ стал главной причиной, по которой эту модель вообще стоило строить.

Представьте стандартный отчёт по промокампании: «Пользователи, применившие промокод, потратили на 800 рублей больше среднего». Бизнес доволен, маркетинг рапортует об успехе. Но подождите, а сколько из них потратили бы эти деньги и без промокода?

Это не риторический вопрос. Это принципиальная проблема, которая называется selection bias — систематическая ошибка отбора.

Я с GitHub Copilot (Claude) собрал полностью локальную RAG-систему с GUI, которая индексирует мои учебники и генерирует по ним отчёты, презентации, конспекты и эссе. Всё работает офлайн. В статье — архитектура, выбор компонентов, процесс совместной разработки с ИИ-ассистентом, грабли и рабочий код.

Я делаю локально работающего ИИ-агента и столкнулся с тем, что стандартный подход «закинуть текст в векторную базу, достать по косинусу» для долгоживущего агента не работает: контекст замусоривается, факты конфликтуют, ничего не забывается. Вместо этого реализовал графовую когнитивную память поверх одного файла SQLite: эпизодические и семантические узлы, типизированные рёбра, именованные сущности, гибридный поиск (FTS5 + vector + graph) с Reciprocal Rank Fusion, кривую забывания Эббингауза и фоновую LLM-консолидацию. В статье — полная архитектура с кодом, SQL-схемой и формулами. Код и минимальный пример — в репозитории.

Внутренние инструменты — это странный жанр. Ты не делаешь продукт для миллиона пользователей. Ты делаешь для двадцати человек, которые будут использовать это каждый день. И если облажалась — они скажут тебе об этом лично. Прямо на созвоне. Иногда с демонстрацией экрана, где всё сломано.

Я занимаюсь этим несколько лет. Python, внутренние сервисы, утилиты, автоматизация. За это время появился довольно конкретный взгляд на то, как надо работать. Не из учебника, а через синяки.

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.

Сейчас есть быстрые альтернативы, например, Polars. Я сам пробовал переводить на него свои проекты. Скорость действительно впечатляет, но как в анекдоте есть нюанс: приходится переписывать чуть ли не весь код и привыкать к новому синтаксису. А это большая работа, на которую не всегда есть время.

И вот здесь я наткнулся на FireDucks — библиотеку, которая обещает решить эту проблему, просто заменив одну строку импорта. Звучало слишком хорошо, чтобы быть правдой. После опыта с Polars я был уверен, что где-то должен быть подвох.

Я решил проверить FireDucks на нескольких типичных задачах. В этой статье я хочу без лишнего хайпа поделиться тем, что у меня получилось. Мы посмотрим на реальные примеры кода, сравним скорость и разберёмся, где эта библиотека действительно хороша, а где могут быть проблемы.

Издательская практика в настоящее время требует оценивать англоязычные книги, а в идеале — отлавливать бестселлеры — задолго до выхода, по первым черновикам. Занятие увлекательное, но порой рискованное. Поэтому в потенциальной переводной книге мы ищем сочетание «широкого контекста» и заключённой внутри него «необходимой новизны». Книга должна быть понятна и интересна широкой аудитории, но не перемалывать в очередной раз широко известные вещи, к тому же разобранные в блогах, а серьёзно облегчать повседневный труд и при этом предлагать ступеньку для роста.

Привет! Меня зовут Николай Олигеров, я работаю продуктовым аналитиком в Яндекс Путешествиях. В этой статье я расскажу, как мы применяли PSM (Propensity Score Matching) — статистический метод, который позволяет корректно сравнивать группы, уменьшая систематические различия между ними. Подробно разберу, как выровнять группы теста и контроля с помощью PSM, расскажу о типичных ошибках (например, утечке признаков), дам практические рекомендации по сбору и выбору фич для мэтчинга, а также покажу, как валидировать полученные результаты и оценить их достоверность.