Python *

В прошлой статье мы разобрали механику событийного цикла asyncio.

В этот раз поговорим о задачах, объектах класса asyncio.Task (они же по‑простому «таски»). Тема важная, потому что по сути вся работа событийного цикла сводится к постоянному жонглированию задачами: запустить, приостановить, разбудить, завершить. Если понять, как устроена таска изнутри, изрядная доля магии asyncio (как и нелюбви к нему) исчезнет.

На десерт шок-контент: почему await далеко не всегда является точкой, где управление возвращается событийному циклу, чтобы он мог переключиться на другую задачу.

Привет, Хабр! Недавно я задумался: Python — не единственный инструмент, которым я хочу оперировать в своих инструментах. Python, понятно, легко освоить и он применяется везде, но язык-то не идеальный! Ресурсов требует много, да и время выполнения не ахти, а учитывая нынешние темные времена... Мне нужно что-то получше. В общем, тут я вздумал попробовать Си.

У меня три ChatGPT-аккаунта. На каждом свои лимиты, своя история, свои причины существовать. И на каждом они кончаются в самый неподходящий момент.

Переключаться вручную то ещё удовольствие. Особенно когда работаешь через Codex CLI или OpenCode и хочешь просто писать код, а не следить за тем, на каком аккаунте сейчас крутится запрос.

Именно под эту боль и написан codex-lb.

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

В 2026 году асинхронный Python уже никого не удивляет. Мы привыкли к автоскейлингу в облаках, но что делать, если ваш бюджет на инфраструктуру равен нулю, а в распоряжении есть только «печка» из 2012 года? Рассказываю про личный опыт выжимания максимума из FastAPI на AMD FX-8320: от тюнинга ядра Linux и PostgreSQL до миграции на Ed25519 и использования Rust-сервера Granian.

За два месяца я перепробовал три ASR-движка, шесть моделей Whisper, адаптивное чанкование, T5-коррекцию и ансамблевое голосование — и большая часть идей оказалась тупиком. В статье — подробный разбор шести тупиков и одной находки: почему GigaAM от Сбера на обычном CPU показывает 3.3% WER на русском, обходя Whisper large-v3-turbo на RTX 4090 (7.9%) в 2.4 раза. С бенчмарками, кодом и честными оговорками.

Привет, Хабр! Меня зовут Владимир, я Python-разработчик в команде IMV в Авито. Мы разрабатываем продукт, который помогает оценивать рыночную стоимость товара, будь то автомобиль, квартира или холодильник. Мы часто пишем тесты, и в этой статье я расскажу, как разные подходы к юнит-тестированию влияют на качество тестов, когда они помогают проекту, а когда — мешают, и почему само по себе наличие тестов ещё не гарантирует пользы. Статья будет полезна разработчикам, тимлидам и всем, кто пишет юнит-тесты и поддерживает код в долгоживущих проектах.

Часто SDET-инженеры, работающие со встраиваемыми системами, не приступают к работе, пока не получат реальное железо: датчик, микроконтроллер или плату с новым чипом. Такой подход обычно оправдывают тем, что без физического девайса «на столе» писать корректно работающий софт невозможно. Очевидный минус: увеличивается время выхода продукта и нового функционала на рынок. Но разработку можно начать, даже не имея в своем распоряжении устройства: все дело в договоренности между командами.

Меня зовут Рустам Ахмадуллин, я старший инженер по системной верификации аппаратуры в YADRO. Расскажу на примере датчика температуры LM75A, как написать API без физического доступа к устройству и его прошивке. Разберем методологию Test Driven Development, при которой разработка начинается с написания автоматизированных тестов, а не самого кода.

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

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

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

Десять лет в девопсе. Десять. И я гуглю tar -xzf. Не раз в год — раз в неделю. Ну, может раз в десять дней, если повезёт. Открываю хром, набираю «tar extract gz linux», пролистываю три рекламы, нахожу ответ на SO, копирую, вставляю, закрываю вкладку. Через неделю — по новой.

Я не идиот. Точнее, может и идиот, но не поэтому. Просто tar — это такой синтаксис, который у меня физически отказывается залезать в долговременную память. Там дефис или нет? xzf или xfz? Или zxf? Вроде порядок не важен? Или важен?..

Короче. Месяц назад я написал скрипт, который это решил. А потом скрипт решил больше, чем я хотел.

Привет, Хабр! (И тебе, питонист, который считает свой язык идеальным, и тебе, JS-ник, у которого уже вышел новый фреймворк, пока ты читал это предложение, и тебе, 1С-ник, который устал объяснять, что ты тоже программист всем во круг.)

Наткнувшись миллионный раз на статью «КАКОЙ ЯЗЫК ПРОГРАММИРОВАНИЯ ВЫБРАТЬ?» я задался вопросом, почему люди ещё не поняли ответа на этот вопрос, ведь он на поверхности.

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

Добрый день! Меня зовут Андрей Слекеничс, я PO GigaIDE, и сегодня мы продолжаем наш экскурс по функциональности GigaIDE.

Первая и предыдущая статьи цикла доступны здесь и здесь. Сегодняшний материал — последний, затрагивающий функциональность GigaIDE Community, и первый, в котором мы переходим к возможностям уже только GigaIDE PRO.

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

Но однажды проект начинает расти.

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

В этой статье пойдет речь об одной из самых сложных и интересных архитектур — трансформере, лежащей в основе современных моделей от OpenAI и Google DeepMind. И это не научпоп для обывателя с наивным уровнем объяснения, а полноценный учебный материал, который поможет вам понять работу трансформера на фундаментальном уровне без черных ящиков типа TensorFlow и Pytorch.

А для того чтобы лучше вникнуть, давайте напишем настоящий мини-трансформер на процедурном Python и обучим его!

Данный материал можно изучать в разных режимах:

* Как объяснение архитектуры для общего представления;

* Как полноценный гайд с чтением кода и самостоятельной практикой;

* Как основу для собственных экспериментов.

Вы сами можете выбрать тот режим, который нужен для ваших целей на данный момент.

Наш трансформер будет довольно простым: со статическим графом и одноблочными энкодером и декодером. Сам код написан в парадигме процедурного программирования (за исключением некоторых модулей) и может быть прочитан на любом уровне и без знания ООП. И все же это будет полноценный обучаемый трансформер с мультиголовым вниманием, батчами данных, параллельным вычислением и множеством параметров.

Для закрепления материала, выполните Домашнее задание, которое ждет вас в конце статьи.

Расскажу, как собрал бота для AI-суммаризации Telegram-каналов: архитектура, выбор LLM-провайдера, оптимизация скорости и неочевидные проблемы при деплое на российский VPS.

340% рост AI-атак за 2025 год, а защита LLM всё ещё — «закиньте промпт в облако, подождите 200ms». Я построил альтернативу: SENTINEL — open-source стек из C, Rust и Python, который фильтрует jailbreak за <3ms on-premise. Ключевая фича — Micro-Model Swarm: рой из моделей <2000 параметров, который ловит то, что не видят регулярки.

Буквально на днях Андрей Карпаты, один из ранних сооснователей OpenAI, покинувший компанию, исследователь нейросетей, опубликовал на Гитхаб фантастическую вещь: чистый (без специализированных библиотек) 200-строчный python-код трансформера, аналога GPT-2, для изучения всеми желающими. И написал в блоге статью для понимания этого кода (и работы трансформеров). Я перевёл статью и комментарии к коду — ведь этот код (я уверен!) войдёт в ИТ-историю...

Присоединяйтесь к этому завораживающему сеансу разоблачения gpt-магии, за считанные годы овладевшей миром!..

Привет, Хабр! Эта задача выглядит как разминка для разогрева: найти максимальное произведение двух чисел в массиве. Но именно с неё началось моё знакомство с алгоритмической культурой — на первом же собеседовании я убедился, что «работает» и «работает эффективно» — разные вещи. В статье — три решения: от интуитивного до элегантного, их сравнение и главный вывод: даже простые задачи учат нас думать.

Привет, Хаброжители!

От выбора подхода к поглощению данных может зависеть успех или провал работы конвейера данных

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

Добрый день. Сегодня я расскажу о том, как я за 2 месяца с полного нуля создал доменную RAG систему с корпусом в 20+ книг.

В статье затрону проблемы парсинга данных (особенно PDF документов, с которыми приходилось иметь дело), чанкинга, создания и индексации эмбеддингов, а также самого интересного – ретривера. Расскажу о latency, трейд-оффах, и сложностях реализации подобных систем локально на ноутбуке (хоть и «игровом») без использования API LLM.

Вся система делалась мной самостоятельно без использования LangChain – это чистый пайплайн от Tesseract, Pillow, MuPDF/Fitz до e5-multilingual, FAISS (+bm25, который я затрону в статье) и Qwen3:8B в качестве LLM.