Python

Cython, Flask и Quart

Evrone digest — Wed, 09 Aug 2023 09:54:54 +0000

Жаркий июль закончился, на дворе август. Нас порадовали мажорным релизом компилятора Cython, которого ждали несколько лет. Также мы решили узнать, в чём разница между двумя микрофреймворками Flask и Quart, а также нашли отличную статью про тонкости популярных конструкций, таких как with…contextmanager. Приятного чтения!

Вышел Cython 3.0

Этого события ждали несколько лет. Причина столь долгой работы над релизом в желании сохранить обратную совместимость с предыдущими версиями Cython. Все актуальные на момент релиза версии CPython поддерживаются в Cython, включая даже экспериментальную 3.12. Python 2.6 на последней валькирии отправился в Вальхаллу, его поддержка была прекращена.

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

Ответ на это безобразие: Pure Python mode, использующий только общепринятый синтаксис Python. Раньше часть кода, например функции для вызова внешних библиотек на C, в этом режиме не поддерживалась. Сейчас же весь код в режиме Pure Python можно «причёсывать» питонячьими линтерами и не испытывать при этом мучительных страданий.

Ещё одним нововведением стала улучшенная поддержка NumPy. Cython давно позволял нативно писать функции внутри NumPy, но в некоторых случаях разработчики натыкались на разного рода ограничения. Теперь же можно, например, писать универсальные функции NumPy прямо в Cython и применять ко всему содержимому структуры данных.

Как часто бывает в мажорных релизах, создатели позаботились и об архитектурных улучшениях. Так что кое-какие внутренние части Cython были переписаны. Это в будущем улучшит совместимость модулей расширения. Написанные для одной версии Python, они должны заработать и на будущих версиях, без регистрации и SMS повторной компиляции.

Вот такие вот нововведения принес нам Cython 3.0. Обновление — хороший повод попробовать его в деле. За деталями советуем заглянуть в детальный Changelog релиза.

Микрофреймворк Quart

Любой Python-разработчик хотя бы раз в жизни слышал про микрофреймворк Flask. Он очень крут, но делает упор на простоту и консервативность. Если вам хочется тоже самое, что и Flask, но стильно, модно, молодёжно — рекомендуем обратить внимание на Quart. Это тоже микрофреймворк для веб-разработки, имеющий несколько важных отличий от Flask.

В комплекте с Quart идёт ASGI (асинхронный серверный интерфейс шлюза). Он поддерживается многими приложениями и платформами, так что с интеграцией не должно возникнуть проблем. Ещё одним способом взаимодействия будет старый добрый WSGI (интерфейс шлюза веб-сервера). Это один из штатных способов объединения нескольких приложений для обработки одного запроса. Реализация этого стандарта описана в PEP 3333.

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

Подведём итог: оба микрофреймворка облегчают жизнь разработчиков, а также делают веб-разработку на Python лёгкой и предсказуемой. Но там, где Flask пользуется исключительно проверенными методами и строго следит за соблюдением концепции микрофреймворка, Quart позволяет себе больше свободы. За счёт этого, его можно назвать более современным и продвинутым.

Разумеется, оба имеют собственные уникальные фичи и ограничения. Но то, что есть альтернатива — приятно.

Тонкости популярных конструкций

О отличие от обычного, синтаксический сахар чаще всего полезен. И в Python его много. Привыкая к удобным конструкциям, мы перестаём задумываться о том, как они устроены внутри и какие задачи призваны решать. Чтобы лучше разобраться во всех этих моментах самому, а также помочь другим, Павел Корсаков из Beeline Cloud написал статью, в которой разобрал конструкцию with…contextmanager.

Присмотритесь повнимательнее к with…contextmanager: напоминает try…except. Если вы тоже поймали себя на этой мысли, то ваша интуиция вас не подвела — именно эта конструкция лежит в основе. Появилась она достаточно давно в таких языках как Ada, C++ и Java. Становится очевидно, что именно там её и подсмотрел Гвидо Ван Россум.

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

Теперь давайте посмотрим на историю with. Этот оператор изначально задумывался в качестве альтернативы try…finally. Чтобы объяснить, как это работает, советуем взглянуть на пример:

def foo(): try: a = 5 / 0 finally: print('finally 1') print('finally 2')

Как только интерпретатор дошёл до try, он запомнил контекст (текущий набор данных). Далее возможно два варианта развития событий:

Если код внутри try не генерирует исключений, то интерпретатор запустит код в блоке finally и далее продолжит выполнение.
Если код внутри try сгенерировал исключение, то после запуска finally программа завершится, т.к. имеется необработанная ошибка.

Очевидно, что в примере выше события будут развиваться по второму варианту. В выводе будет «finally 1» и код ошибки. Вывода «finally 2» мы не увидим.

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

За подробностями и примерами с with…contextmanager, рекомендуем заглянуть в оригинальный текст статьи на Хабре. И если она вам понравилась, то не поленитесь поставить автору плюс в карму.

Митапы

Онлайн

Python meetup

29 ноября 2023

Рады сообщить, что у нас запланирован осенний Python Meetup. Программа мероприятия формируется. Заявки на участие спикера принимаются до 10 ноября.

Теперь следить за митапами Evrone стало удобнее. В Telegram-канале Evrone meetups мы выкладываем анонсы с подробными описаниями докладов, а также студийные записи после мероприятий. А ещё, у нас можно выступить, мы поможем оформить вашу экспертизу в яркое выступление. Подписывайтесь и пишите @andrew_aquariuss, чтобы узнать подробности.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Мы рады новым Python-разработчикам. Удалённая работа с первого дня, помощь в подготовке выступлений на профессиональных конференциях, поощрение и оплата участия в Open-source проектах. Прозрачный способ увеличить грейд через обучение и проверку навыков под контролем ментора. Здесь есть понимание как организовать разработку комфортно и эффективно. Присоединяйтесь!

Подробнее

Особое мнение

Evrone digest — Wed, 05 Jul 2023 12:53:11 +0000

Глобальные задачи и новые языки, мнения экспертов и полезные инструменты. Вы на частоте Evrone, здесь мы говорим о самом интересном из мира Python-разработки. Спасибо, что вы с нами, и приятного чтения!

Привет от SkyNet

Сколько человечество существует, столько оно любит развлекать себя нерешаемыми задачами. Алхимики пытались создать магистериум, он же великий эликсир, он же философский камень. Целью было превращать любой металл в золото, быть универсальным лекарством и продлевать жизнь. Такой же привлекательной и неосуществимой была идея вечного двигателя, perpetuum mobile. И если в 1635 году первый патент на такое устройство выдали, то к 1775 заявки принимать перестали. Всем к тому времени стало очевидно, что создать такое устройство невозможно.

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

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

Один из таких проектов привлёк наше внимание своей необычностью. Цель Automata — создать ИИ-программиста, который будет самостоятельно проектировать, писать, тестировать и совершенствовать сложные системы. При этом он сможет самостоятельно обучаться, а также дорабатывать свой собственный код, существенно повышая свою автономность и способность к изобретению новых алгоритмов. Таким образом, если проект достигнет успеха, то Automata станет первым в мире, полностью автономным ИИ.

За основу взяты большие языковые модели, такие как GPT-4 и векторная база данных. По замыслу разработчиков этого достаточно для создания системы, способной самостоятельно искать, писать и документировать код. Авторы вдохновились теорией автоматов, гласящей, что код по своей сути может быть формой памяти и потенциально привести к созданию Общего ИИ (General AI). Станет ли это концом человечества, как нас предупреждал Стивен Хокинг, или нет — вопрос остаётся открытым. Но мы будем периодически наведываться в репозиторий. Просто так, на всякий случай.

Так ли хорош Mojo

В мае 2023 интернет вскипел от хвалебных постов в адрес нового языка программирования Mojo. Ему стали пророчить будущее величайшего достижения в Computer Science, а его релиз будет главным событием в мире разработки программного обеспечения. Демоверсия примеров кода на Mojo показала результат в 35’000 раз быстрее, чем на обычном Python. Мы не стали верить этому на слово и решили не спешить с выводами. Предлагаем посмотреть на Mojo без розовых очков, когда шумиха уже улеглась.

Mojo разрабатывается стартапом Modular, во главе которого стоит Крис Лэттнер. Ранее он был ключевым разработчиком LLVM, MLIR, Clang и языка Swift. Такой послужной список, вместе с опытом работы в Google, Tesla и Apple, говорит о крайне высокой квалификации. Второй основатель Тим Дэвис, также опытный разработчик, ранее работал над Tensorflow. Остальные участники проекта зарекомендовали себя в сфере разработки компиляторов, фреймворков и машинного обучения.

Ключевым элементом языка будет MLIR. Это компилятор, в основе которого лежит идея расширяемости и возможности переиспользования инфраструктуры. Изобретать собственный синтаксис не стали, взяв его из Python. Это решение позволит не придумывать велосипед, а сразу сделать Mojo привычным для всех, кто уже программирует на Python. Более того, используется метод Dogfooding (Eating our own dog food), при котором создание языка ведется с помощью уже созданных элементов этого языка. Примерно также, как в Julia всё построено с использованием Julia.

Вместо однозначно определённой системы типов будет гибрид между статической и динамической. Если для определения функции разработчик использует ключевое слово fn, то будет применена высокопроизводительная статическая типизация. В этом случае нужно будет определить тип каждого идентификатора, а Mojo сможет оптимизировать создаваемый машинный код. Если использовано слово def — останется обычная динамическая типизация и типы будут выбираться языком самостоятельно с возможностью их менять во время выполнения кода. Так можно будет точечно ускорять конкретные функции, не слишком усложняя код.

Поразительные итоги демоверсии, с одной стороны, выглядят чистым маркетингом. Расчёт множества Мандельброта — абсолютно синтетический бенчмарк. В реальном приложении такого феноменального ускорения достичь вряд ли получится. С другой стороны, команда, ведущая разработку Mojo, имеет опыт и экспертизу работы над сложными проектами. Это, в свою очередь, позволяет верить в успех. Волна хайпа утихла, но скорее всего мы ещё услышим о Mojo и о том, чего удалось достичь команде Modular.

Альтернативное мнение: asyncio

Asyncio решил много проблем в Python. Асинхронное программирование стало нативным, частью языка. Костыли больше не требовались, а множество разработчиков вздохнули с облегчением. Но не всем это нововведение пришлось по душе. Некоторые программисты, такие как Чарльз Лейфер, даже спустя 8 лет считают его дестабилизирующим фактором, порождающим ужасный дизайн.

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

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

Если же асинхронность именно то, что вам нужно, то есть альтернативный способ её добиться. Библиотека gevent отличается от asyncio тем, что преобразует все блокирующие вызовы в неблокирующие и возвращает управление в event loop. Интерфейс gevent сильно напоминает treading module из Python, что делает его знакомым для программистов, ранее использовавших параллелизм на основе потоков. Ну а использовать его или нет — решение, в любом случае, за вами.

Подсказываем в CLI

Закончим наш дайджест полезным инструментом — библиотекой arguably. Она помогает превратить ваши функции и строки документации в интерфейсы командной строки. С интеграцией не должно возникнуть никаких проблем. Всё, что скрипт должен преобразовать, надо задекорировать с помощью @arguably.command, а затем вызвать с помощью arguably.run().

Возьмём небольшой пример, назовём его intro.py:

#!/usr/bin/env python3 import arguably @arguably.command def some_function(required, not_required=2, *others: int, option: float = 3.14): """ this function is on the command line! Args: required: a required argument not_required: this one isn't required, since it has a default value *others: all the other positional arguments go here option: [-x] keyword-only args are options, short name is in brackets """ print(f"{required=}, {not_required=}, {others=}, {option=}") if __name__ == "__main__": arguably.run()

Результатом выполнения кода станет следующее:

user@machine:~$ ./intro.py -h usage: intro.py [-h] [-x OPTION] required [not-required] [others ...] this function is on the command line! positional arguments: required a required argument (type: str) not-required this one isn't required, since it has a default value (type: int, default: 2) others all the other positional arguments go here (type: int) options: -h, --help show this help message and exit -x, --option OPTION keyword-only args are options, short name is in brackets (type: float, default: 3.14)

Библиотека arguably автоматически создала подсказку, которая позволит пользователям сходу разобраться, какие аргументы необходимо указать и в каком формате. Отдельно отметим, что поддерживаются разные языки разметки документации: reStructuredText, Google, Numpydoc и Epydoc.

Установка производится через pip:

pip install arguably

Если эта библиотека вам понравилась, то не забудьте заглянуть в репозиторий и поставить звёздочку. Уверены, что автору будет приятно.

Интересно посмотреть

Пропустили наш предыдущий митап? Не страшно! Видеозаписи докладов уже выложены на нашем YouTube-канале в кинематографическом качестве 4K и со студийным звуком.

Александр Мещеряков из Сinimex рассказал, как развертывать модели с использованием геопространственных данных и отобразить исходную информацию на карте с помощью визуализации геоданных:

Дмитрий Савостьянов из Artifactory поделился опытом использования ML-модели прогнозов платежей клиентов и системы предсказания спроса, разработанной в компании. Монетизация в мобильных играх строится на внутриигровых продажах, обычно платят не более 10% пользователей. Поэтому очень важно удерживать платящих игроков. Для такой предиктивной аналитики геймдевы решили использовать машинное обучение:

Мария Изофатова из Мегафон объявила месяц борьбы с уязвимостями кластера Apache Hadoop: репартиционирование (проблема мелких файлов), автоочищение таблиц на кластере, настройка конфигурации PySpark, анализ запущенных Spark application и внутреннего кода:

Подписывайтесь и ставьте 🔔колокольчик, чтобы получать уведомления о будущих трансляциях и видео! А ещё присоединяйтесь к Telegram-каналу и будьте в курсе всех наших будущих мероприятий.

Митапы

Онлайн

Python meetup

11 октября 2023

Рады сообщить, что у нас запланирован осенний Python Meetup. Программа мероприятия формируется. Заявки на участие спикера принимаются до 20 сентября.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Расширяем кругозор

Evrone digest — Wed, 07 Jun 2023 12:25:31 +0000

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

Лайфхаки с Makefile

При разработке любого проекта на Python есть масса рутинных операций: тесты, запуск приложения в контейнере или прогон кода линтером. И не стоит плодить лишние сущности в виде shell-скриптов под каждую такую задачу. Можно использовать встроенный в IDE task runner или даже поставить какой-то внешний инструмент, но есть решение элегантнее и проще. В состав любого Linux-дистрибутива или macOS с древних времён входит такая штука, как Makefile. Её типичное применение — собирать код на C, но де-факто это крутое средство автоматизации любых задач.

Проще всего объяснить, как это работает, на примере кода. Идеальный пример был найден в блоге Антона Жиянова, разработчика на Python и Golang. Вот как может выглядеть простейший Makefile:

coverage: ## Run tests with coverage coverage erase coverage run --include=dadata/* -m pytest -ra coverage report -m deps: ## Install dependencies pip install black coverage flake8 mypy pylint pytest tox lint: ## Lint and static-check flake8 dadata pylint dadata mypy dadata push: ## Push code with tags git push && git push --tags test: ## Run tests pytest -ra

Прогон несколькими линтерами и тестирование? Легко:

$ make lint coverage

Запушить с тегами в репу? Ещё проще:

$ make push

Из примера видно, что можно создавать цепочки действий, каждое из которых будет выполнено в отдельном подпроцессе (как в coverage или lint). Если надо выполнить связанную между собой цепочку действий, то объединение делается через два амперсанда && (как в секции push).

Внутри этого же Makefile можно легко определить зависимости между задачами. Тут, например, тесты не будут запущены, пока не выполнен линтинг:

test: lint pytest -ra

Есть даже возможность явного вызова задач прямо внутри Makefile:

lint: flake8 dadata pylint dadata mypy dadata test: pytest -ra prepare: make lint make test

Освоив эти нехитрые приёмы, можно переходить к более сложным трюкам. В этом поможет статья Makefile tricks for Python projects. Там вы найдёте полезные советы не только по составлению Makefile, но и по настройке оболочки операционной системы. Например, для BASH можно флагами отключить встроенные правила и добавлять дополнительную информацию в вывод, если операция завершилась неудачей:

SHELL := bash .SHELLFLAGS := -eu -o pipefail -c MAKEFLAGS += --warn-undefined-variables MAKEFLAGS += --no-builtin-rules

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

Пишем в стиле Rust

Всю жизнь писали на Python, а потом решили попробовать Rust? Скорее всего вы испытаете те же чувства, какие испытывает хулиган, оказавшись в английской школе 19го века. Величественно, строго и могут высечь розгами (вспомните, как наказывали Тома Сойера).

Строгость системы типов и другие особенности языка вначале доставляют много боли и страданий. Но если все требования Rust удовлетворены, это гарантирует, что код будет работать очень быстро, и не упадёт по неизвестной причине. Значит ли это, что надо бросить всё и срочно учить другой язык? Вряд ли! А вот привнести немного порядка и строгости в Python вы можете самостоятельно, взяв за основу те же концепции, которые применены в Rust.

Начать можно с малого — подсказок типа. Возьмём вот такую простейшую функцию:

def find_item(records, check):

Эта строка несёт в себе очень мало информации. Records — это список, словарь или вообще соединение с базой данных? А что за check? Это булево значение или какая-то другая функция? Если функция, что она вернёт? А если сбой, то получим ли мы исключение или None? Масса вопросов и ноль ответов. Теперь давайте перепишем эту функцию на аналогичную. А на вопросы сразу ответим, используя встроенный механизм подсказок:

def find_item( records: List[Item], check: Callable[[Item], bool] ) -> Optional[Item]:

Стало понятно, что такое records и check. А главное, мы сразу видим, какого они должны быть типа. Написать такой код легко и не слишком долго. Зато потом в нём легко будет разобраться и найти потенциальные ошибки. Теперь, когда у нас есть удобное и внятное описание, пришла пора сделать интерфейсы более точными и защищёнными от неожиданностей. Вернуть несколько значений (или одно сложное значение) из функции можно несколькими способами. Проще всего вернуть кортеж или словарь, но оба этих способа на выходе дадут нечто, что придётся изучать. Вот пример кортежа:

def find_person(...) -> Tuple[str, str, int]:

Вернулись три каких-то значения. Придётся внимательно изучать функцию, чтобы выяснить их значение. Словарь тоже не решит ситуацию:

def find_person(...) -> Dict[str, Any]: ... return { "name": ..., "city": ..., "age": ... }

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

Решением станет возвращать строго типизированный объект. Каждый параметр такого объекта должен иметь ассоциированный тип. Это автоматически подводит нас к решению о создании класса, а чтобы не усложнять жизнь, его можно создать при помощи dataclasses:

@dataclass class City: name: str zip_code: int @dataclass class Person: name: str city: City age: int def find_person(...) -> Person:

Так гораздо информативнее. Мы сразу же получаем явное описание того, что возвращает функция. Автодополнение IDE начнёт работать эффективнее, показывая имена и типы атрибутов. При рефакторинге и изменении атрибутов средство проверки типов и IDE укажут на все места, которые нужно изменить. Даже запускать программу не потребуется. Хотите узнать больше, тогда рекомендуем заглянуть в статью Writing Python like it's Rust чешского программиста Якуба Беранека (Jakub Beránek).

CLI prompts без ncurses

Мы в Evrone любим удобные и легковесные инструменты. Сегодня кратко расскажем об одной простой и красивой библиотеке survey для создания подсказок. Её автор вдохновлялся одноимённой библиотекой из языка Go. С помощью survey можно создавать интерактивные подсказки с множеством дополнительных возможностей. При этом она самодостаточна и не требует дополнительных зависимостей, таких как ncurses.

Библиотека имеет хорошо структурированную документацию с кучей гифок, демонстрирующих для чего её можно применять. Используется принцип конструктора, где каждая фича представлена в виде виджета. Комбинируя их, можно создавать действительно удобные пользовательские интерфейсы для консоли. Там учтено множество моментов, основанных на опыте использования разных операционных систем. Так, например, пользователи привыкли, что при введении паролей, они видят количество символов, замаскированных звёздочками. В survey есть соответствующий виджет Conceal:

value = survey.routines.conceal('Password: ') print(f'Answered {value}.')

Если стоит задача сделать удобную форму, то это легко делается одноимённым виджетом Form:

form = { 'name': survey.widgets.Input(), 'price': survey.widgets.Count(), 'type': survey.widgets.Select(options = ('food', 'stationary', 'tobacco', 'literature')) } data = survey.routines.form('Item Data: ', form = form)

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

Python на мобильных

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

Время идёт, а легче не становится. Среди мобильных экосистем всё ещё жёсткая конкуренция, так что если вы пишете под Android на каком-нибудь Kotlin, то на iOS такое приложение простым способом не портировать. Частично ситуацию решает фреймворк Flutter для языка Dart. Он позволяет иметь единую кодовую базу, но при этом созданные приложения заработают и на десктопных системах, и на смартфонах из разных экосистем.

Проект BeeWare служит той же цели и даёт возможность разрабатывать приложения на Python, которые бы работали на разных мобильных устройствах и могли бы нативно задействовать возможности этих устройств. Эта идея возникла очень давно, но до недавнего времени проект выглядел как чьё-то хобби и поддерживался энтузиастами во главе с Расселом Кит-Маги (Russel Keith-Magee). Теперь же компания Anaconda увидела потенциал BeeWare и стала его финансировать, что позволило Расселу заниматься им full-time вместе с коллегой, Малькольмом Смитом (Malcolm Smith).

На Python Language Summit в этом году прозвучало интересное предложение. Рассел предложил включить Android и iOS в список платформ уровня Tier 3 от CPython в Python 3.13. Переводя с «питонячьего бюрократического», это означает, что как минимум один основной разработчик CPython возьмёт на себя обязательство поддерживать работу интерпретатора на этих платформах.

Точно такой же уровень поддержки уже присвоен платформам emscripten, WASI и FreeBSD. Основная проблема и препятствие на этом пути — запуск тестов на мобильных платформах в CI. Именно это препятствие Рассел устранил, создав Briefcase. Будучи одним из инструментов упаковки и разработки BeeWare, Briefcase может закрыть вопрос с тестированием.

Разумеется, впереди будет ещё масса специфических вопросов. Например, iOS полностью аутентична, а вот Android во многом схож с Linux. С первой ОС всё понятно и она может быть легко указана, как sys.platform == “ios”. А вот Android может быть либо указан как sys.platform == “android”, либо как sys.platform == “linux”.

Второй вариант, по словам Рассела, оптимален, поскольку большая часть кода будет работать на Android сразу, даже если возможность запуска на этой платформе не учитывается. Так что если предложение будет принято, возможно мы получим возможность писать приложения на Python, которые будут отлично работать на всех современных смартфонах.

Митапы

Онлайн

Python meetup

28 июня 2023

Рады сообщить, что у нас запланирован летний Python Meetup. Программа мероприятия формируется. Заявки на участие спикера принимаются до 10 июня. Видео с предыдущего митапа в студийном качестве 4K уже выложены на нашем YouTube-канале.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Mastodon-бот, urllib3 v2.0.0 и TOTP

Evrone digest — Wed, 10 May 2023 13:16:55 +0000

В сегодняшнем дайджесте посмотрим, как создать бота для Mastodon, отпразднуем с сообществом выход urllib3 v2.0.0 и расскажем про реализацию алгоритма TOTP всего в 20 строках кода.

Разработка Mastodon-бота на Python

Илон Маск продолжает агрессивную монетизацию Twitter. Доступ к API стал платным и это поставило крест на создании бесплатных ботов для интерактивных коммуникаций. Свято место пусто не бывает — всё больше разработчиков выбирают в качестве платформы децентрализованную self-hosted социальную сеть Mastodon. Каждый сервер (участник сети) может иметь собственные правила и не подчиняется какой-то единой политике.

Чтобы попрактиковаться в создании Mastodon-ботов, можете попробовать инстанс botsin.space. Список правил, которые необходимо соблюдать людям и ботам описан в их Code-of-Conduct. Чтобы не изобретать велосипед, в качестве оболочки для API имеет смысл выбрать библиотеку Mastodon.py.

Минимальный пример в стиле Hello, world! будет выглядеть так:

from mastodon import Mastodon # Create an instance of the Mastodon class mastodon = Mastodon( access_token='your_access_token_here', api_base_url='https://your.instance.url' ) # Post a new status update mastodon.status_post('Hello, Mastodon!')

Автоматический ответ на упоминания имени пользователя в toots (аналог твита в Twitter) можно выразить вот таким кодом:

# Define a function to handle mentions def handle_mention(status): if '@your_bot_username' in status.content: mastodon.status_post('@' + status.account.username + ' Hello there!') # Start streaming for mentions mastodon.stream_user(handle_mention)

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

urllib3 v2.0.0 вышел в релиз

HTTP-клиент urllib3, о котором мы неоднократно упоминали в наших дайджестах, получил долгожданное обновление до версии 2.0.0. Выпущенный 12 лет назад, он стал настоящим сокровищем и был загружен более 8 млрд раз. За прошедшие годы разработчики пришли к выводу, что необходимо провести большой рефакторинг и результатом стала версия 2.0.0. Мы детально взглянули на релиз и готовы поделиться некоторыми выводами.

Просьбы пользователей о появлении высокоуровневой функции urllib3.request() были услышаны. Теперь можно делать HTTP-запросы и не беспокоиться о сложности процессов, лежащих в основе функции. В сети уже появились гайды с примерами, основанными на новой фиче, вот один из примеров:

import urllib3 resp = urllib3.request("GET", "https://example.com") print(resp.status) # 200 print(resp.headers.get("Content-Type")) # text/html; charset=UTF-8

Кажется, принцип KISS здесь был задействован на полную катушку. Второй важной и полезной возможностью стала встроенная поддержка JSON в API-интерфейсах запросов и ответов. Это автоматически упрощает код и позволяет взаимодействовать с API-интерфейсами HTTP через JSON:

import urllib3 resp = urllib3.request( "POST", "https://httpbin.org/anything", # The 'json' parameter encodes the JSON into the body # and sets the 'Content-Type' to 'application/json'. json={"key": "value"} ) # The HTTPResponse.json() method decodes JSON in the body # and loads the data into a Python object. print(resp.json())

Отдельно декодировать JSON не требуется, мы сразу получаем на выходе объект с данными:

{ "headers": { "Accept-Encoding": "identity", "Content-Length": "15", "Content-Type": "application/json", "Host": "httpbin.org", "User-Agent": "python-urllib3/2.0.0" }, "json": { "key": "value" }, "method": "POST", "url": "https://httpbin.org/anything" }

Красота, да и только. Ну и третье существенное изменение коснулось отсутствующего в Python понятия безопасности типов. Если функция принимает строковый параметр, а вы в неё отправите целочисленный, то интерпретатор не поднимет тревоги. Правда, функция при этом, скорее всего, тоже не заработает правильно. Начиная с версии 2.0.0, urllib3 обзавёлся строгими подсказками типов.

Кстати, команда разработчиков ещё пару лет назад написала статью о том, с какими нестандартными проблемами они столкнулась в процессе реализации этой фичи. Ну а если вам интересны все нововведения второй версии, советуем заглянуть в Changelog релиза.

TOTP в 20 строках кода

Алгоритм TOTP (Time-Based One-Time Password) —«священный грааль» инициативы OATH (Initiative for Open Authentication). Этот алгоритм применяется в качестве составляющей двухфакторной или мультифакторной авторизации, дополняя традиционные механизмы на основе паролей, кодовых фраз, аппаратных токенов и прочих.

TOTP-коды остаются действительными лишь короткий отрезок времени, после чего «протухают». Штатно код меняется каждые 30 секунд. Если школьник Вася перехватит данные с помощью трояна, то у него будет лишь несколько секунд, чтобы ими воспользоваться. Не печалься, Вася! Ещё станешь хорошим хакером! А мы пока посмотрим на внутреннее устройство TOTP.

«Сердцем» TOTP является алгоритм HOTP (HMAC-based One-Time Password). HMAC, как часть этого алгоритма, гарантирует, что в случае перехвата сообщения атакующий не сможет угадать длину или расшифровать сообщение без наличия ключа или кода. Если вы планируете задействовать TOTP, советуем обратить внимание на проект MinTOTP. Авторы явно задались целью сделать настолько минималистичный код, насколько это возможно. Полноценная реализация заняла всего 20 строк кода (30 с начальным шебангом и пустыми строками):

#!/usr/bin/env python3 import base64 import hmac import struct import sys import time def hotp(key, counter, digits=6, digest='sha1'): key = base64.b32decode(key.upper() + '=' * ((8 — len(key)) % 8)) counter = struct.pack('>Q', counter) mac = hmac.new(key, counter, digest).digest() offset = mac[-1] & 0x0f binary = struct.unpack('>L', mac[offset:offset+4])[0] & 0x7fffffff return str(binary)[-digits:].zfill(digits) def totp(key, time_step=30, digits=6, digest='sha1'): return hotp(key, int(time.time() / time_step), digits, digest) def main(): args = [int(x) if x.isdigit() else x for x in sys.argv[1:]] for key in sys.stdin: print(totp(key.strip(), *args)) if __name__ == '__main__': main()

Модуль hmac нужен для реализации HOTP и берётся из стандартной библиотеки. HOTP принимает на вход секретный ключ, закодированный в Base32 и счётчик. На выходе выдаётся 6 цифр. Функция TOTP фактически служит “обёрткой” для HOTP с подсчётом временных интервалов, начиная с Unix epoch (1970-01-01 00:00:00 UTC). Практично, удобно… Рекомендуем!

Митапы

Онлайн

Python meetup

28 июня 2023

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Pandas 2.0 и асинхронный агностицизм

Evrone digest — Fri, 07 Apr 2023 11:17:39 +0000

Апрель 2023 порадовал мажорным обновлением Pandas, самой известной библиотеки для анализа данных. Ещё мы рассказали о трудностях дистрибуции Python-приложений в экосистеме macOS, способах запуска приложений в браузере с помощью PyScript и асинхронном фреймворке Textual.

Долгожданный Pandas 2.0

Самая популярная библиотека для анализа данных обновилась до версии 2.0. Основным изменением стала интеграция с Apache Arrow. Это такой унифицированный формат хранения данных в памяти. Ранее Pandas использовал только библиотеку NumPy, которая была не всегда эффективной при работе с такими структурами данных, как DataFrame.

«Если хочешь сделать что-то хорошо, сделай это сам», — эта цитата Фердинанда Порше отлично отражает то, что сделал создатель Pandas, Уэс МакКинни (Wes McKinney). 10 лет назад он выступал с докладом о проблемах производительности, а спустя 4 года стал соучредителем Apache Arrow. Новый релиз соединил в себе сильные стороны обоих проектов.

Pandas часто критиковали за несколько особенностей. Отсутствующие значения долгое время были «головной болью» для специалистов по анализу данных. Они вызывали неявное изменение типа данных. Отсутствующие значения могли иметь разный тип, что в конечном итоге влияло на конечный dtype. Arrow решает эту проблему «из коробки»:

In [1]: df2 = pd.DataFrame({'a':[1,2,3, None]}, dtype='int64[pyarrow]') In [2]: df2.dtypes Out[2]: a int64[pyarrow] dtype: object In [3]: df2 Out[3]: a 0 1 1 2 2 3 3 <NA>

Второй особенность, за которую Pandas часто ругали — неэффективное управление строками. Оно и понятно — NumPy создавался вовсе не для обработки строк, а для числовых расчётов. Так что столбец со строковыми данными представлял собой набор указателей PyObject. Сами же данные были хаотично разбросаны по куче. Ни о какой эффективности тут речь, разумеется, не идёт. Промахи кэша и увеличенное потребление памяти — два постоянных спутника.

Чем больше было данных, тем ситуация становилась хуже. Даже экспериментальное расширение StringDtype не улучшило ситуацию. Apache Arrow архитектурно лишён этих недостатков и обращается с памятью эффективнее. Приятным бонусом стало существенное увеличение скорости (до 10 раз быстрее, чем NumPy) и уменьшение использования памяти (более чем в 2 раза).

Также внедрили механизм CoW (Copy-on-Write). Он часто используется в других системах для уменьшения накладных расходов на копирование. Это повышает безопасность данных, при использовании операций индексирования, а также производительность при совместной работе.

Пишем приложения для macOS

Python считается одним из наиболее универсальных языков. На нём можно написать всё что угодно. Но иногда простая задача написать приложение под macOS и распространить его, может превратиться в целый квест. Такая история была опубликована в блоге Python-разработчика Глифа Лефковица (Glyph Lefkowitz).

Экосистема Apple кажется заточенной под правильного разработчика, пишущего проприетарный код в нативном XCode на каком-нибудь Swift и платящего за учётную запись $99 в год. Конечно же, только на оборудовании Apple.

Если же вы на любом другом сетапе пишете приложение с открытым исходным кодом на Python в каком-нибудь VSCode или PyCharm — столкнётесь с рядом сложностей при попытке распространить его в экосистеме Apple. Чтобы подписать приложение, понадобится валидная учётная запись на портале Apple Developer. Можно использовать и веб-портал или ещё проще — подписать через XCode. Эта поистине монструозная IDE, весом в 11 Гб. Боль для тех, у кого нет доступа к высокоскоростному интернет-каналу.

Предположим, всё это пройдено и приложение подписано. Возникает новое препятствие — приложение должно быть подписано самой Apple, процедура «notarization». Подпись с заверением делается с помощью усиленной среды исполнения. Последняя несовместима с множеством вещей в Python, таких как cffi или ctypes. А если в пакете есть внутренние симлинки, то вообще пиши пропало.

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

Python в браузере

Всё больше интересных идей превращаются в готовые приложения с открытым исходным кодом. Проект PyScript начался с идеи «Было бы круто иметь возможность запускать код на Python прямо внутри браузера». Давайте возьмём Pyodide (портированный CPython), прикрутим к нему WASM и используем HTML в качестве интерфейса. Немного магии и мы получаем фреймворк для создания приложений на Python, которые будут работать везде, где есть современный браузер.

Попробовать PyScript можно тремя способами. Самый простой — на сайте проекта есть 18 демонстрационных примеров. Запуск любого приводит к открытию вкладки, загрузке Pyodide и запуску заранее написанного кода.

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

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

Третий же способ — локальное развёртывание. В нужную веб-страницу добавляете скрипт и таблицу стилей:

Сам же код прописываете непосредственно в веб-странице, например:

<py-config> plugins = [ "https://pyscript.net/latest/plugins/python/py_tutor.py" ] </py-config> <section class="pyscript"> Hello world! <br> This is the current date and time, as computed by Python: <py-script> from datetime import datetime now = datetime.now() display(now.strftime("%m/%d/%Y, %H:%M:%S")) </py-script> </section>

Сохраняете, приложение заработает. Никаких дополнительных телодвижений не требуется.

Не асинхронная асинхронность

Реализация асинхронного программирования с помощью паттерна async/await в Python 3.5 стало важным событием. С того момента можно было создавать сопрограммы, вычисления в которых не блокировали работу приложения. Это давало существенный прирост производительности. Особенность асинхронного программирования в том, что оно оптимизирует время исполнения и позволяет избежать простоев процессора.

Но у асинхронности есть и недостатки. По мнению эксперта по Python, Уилла МакГугана (Will McGugan), основная проблема асинхронности в том, что она имеет тенденцию бесконтрольного размножения в коде. Разработчики начинают использовать async для одного-единственного вызова или ещё хуже — добавляют async просто так, на всякий случай.

Но ведь паттерн async/await вовсе не единственная асинхронная техника. Есть ещё одна интересная, называется «Await me maybe». Она отлично работает с библиотекой asyncio. Термин впервые был придуман Саймоном Уиллисоном (Simon Willison). Смысл в том, чтобы асинхронная функция могла запускать callback либо с запланированной (неасинхронной) функцией, либо с корутиной (асинхронной через async def). Выглядит это следующим образом:

import asyncio import inspect def plain_old_function(): return "Plain old function" async def async_function(): return "Async function" async def await_me_maybe(callback): result = callback() if inspect.isawaitable(result): return await result return result async def run_framework(): print( await await_me_maybe(plain_old_function) ) print( await await_me_maybe(async_function) ) if __name__ == "__main__": asyncio.run(run_framework())

Этот паттерн лёг в основу асинхронного фреймворка Textual. Он вообще не требует от разработчика использования ключевых слов async/await, хотя и позволяет расставить их по коду. Если захотите попробовать его в деле, то гайд по быстрому старту есть на сайте проекта.

Интересно посмотреть

Мы рады делиться экспертизой наших специалистов. На YouTube-канале Evrone Academy появилось много новых обучающих видео. Даже если вы давно пишете на Python, иногда полезно освежить знания и сверить их с другими экспертами. Ну а для новичков эти видео могут стать отличной отправной точкой.

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

Митапы

Онлайн

Python meetup

28 июня 2023

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Опаснее, быстрее, умнее

Evrone digest — Thu, 09 Mar 2023 14:43:41 +0000

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

Ещё одна серия атак на PyPi

Американская компания Phylum специализируется на безопасности цепочек поставок. Их команда исследователей и программистов разработала автоматизированную платформу, постоянно отслеживающую необычные публикации на PyPI. 23 февраля 2023 года эта система зафиксировала аномальную активность. Количество опубликованных пакетов быстро увеличивалось с нескольких десятков до нескольких сотен. Новые пакеты публиковались каждые 4-8 секунд.

Основная опасность каждого из таких пакетов состояла в том, что файл setup.py имел фрагмент, вызывающий команду Powershell. Сама команда была закодирована в Base64, чтобы не привлекать лишнего внимания. В расшифрованном виде эта команда выполняет веб-запрос в Dropbox, где лежит вредоносная нагрузка: дроппер на Rust. Но это лишь «верхушка айсберга» и первый этап заражения. Далее вредонос вызывает второй этап и сброс на диск нескольких бинарников. Каждый из них служит для маскировки под легитимные программы, если судить по названиям.

Одно из названий весьма примечательно — Esquele.exe. Гугл-переводчик переводит esquele, как искажённое слово «скелет» (esqueleto) на испанском языке. Тоже самое определение дают и генеративные нейросети — ChatGPT и NotionAI. Весьма точное наименование для дроппера. (прим. автора)

Детальный анализ механизма атаки позволил найти сходство с той, которую платформа зафиксировала в январе 2023 года. Тогда были опубликованы три библиотеки httpslib, colorslib и libhttps, в установочном коде которых был схожий порядок команд и маскировки, вроде переименования бинарника в WindowsCache.exe. Специалисты Phylum подозревают, что январская атака была лишь разминкой и тестированием эффективности. Так что советуем быть крайне осторожными при использовании PyPI, вероятнее всего атака продолжается и на момент публикации этого дайджеста.

Google Python Style Guide

Хороший код, как и хороший текст, начинается с правил и соглашений. Такой сборник может носить разные названия: coding standard, style guide, code style, programming style и тому подобные. Целью является единообразие, консистентность и отсутствие конфликтов между разными участниками команды. При этом новым разработчикам значительно проще адаптироваться к чтению кода, не упираясь в специфическое оформление. Общие стандарты развивают культуру разработки и улучшают комфорт чтения кода.

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

Авторы документа составили его в виде списка советов. Их можно разделить на две категории: что стоит делать, а чего лучше избегать. Любители Vim останутся довольны, ведь им подготовили файл настроек, помогающий корректно форматировать код. А вот для Emacs прекрасно подойдут и дефолтные настройки. Упоминается также использование инструментов автоматического форматирования Black и Pyink.

Отдельно отметим, что каждая рекомендация имеет чёткое обоснование и отвечает на вопрос «почему так, а не иначе?». Если какой-то совет может быть неоднозначным, то приводятся как плюсы, так и минусы решения. Большое внимание уделяется правильному комментированию кода, но при этом авторы советуют не пытаться описывать его. Что логично — люди, читающие ваш код, вполне могут разбираться в Python лучше вас. Здесь много советов из серии «Капитан Очевидность», но это всё равно полезно, ведь никто не может идеально знать все детали и нюансы.

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

Экстремально быстрый линтер ruff

Если загуглить, какой из линтеров стоит выбрать, то чаще всего предлагается два самых популярных: Pylint и Flake8. Оба этих инструмента работают отлично, но в больших проектах имеет значение другой фактор — скорость. В этом плане можно привести в пример экосистему вокруг JavaScript, где тулинг должен работать очень быстро. Использование быстрых языков, таких как Go и Rust, в swc, esbuild и Rome позволило получить изначально высокую производительность. А раз такой подход сработал для JS, то вполне подойдёт и для Python.

Ruff — это Proof-of-Concept сразу двух идей:

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

Всё это легко подтверждается бенчмарками. В качестве языка был выбран Rust и это действительно сделало линтер на 1-2 порядка быстрее конкурентов. Замеры на кодовой базе CPython показали, что Ruff работает молниеносно:

Доходит до смешного. Sebastián Ramírez (интервью с ним есть на нашем сайте), автор FastAPI, признался, что иногда добавляет преднамеренные ошибки в код. Так можно убедиться, что Ruff запущен и исправно функционирует. Вишенкой на торте может стать то, что несколько дней назад разработчики линтера Pylint начали переходить с Flake8/Autoflake именно на Ruff. Будем следить за его развитием и обязательно расскажем о нём в будущих дайджестах.

Локальный аналог CoPilot

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

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

Но что, если всё-таки хочется получить локального AI-помощника на своей машине? У модели OpenAI Codex, на которой построен CoPilot, есть бесплатный конкурент — CodeGen. Он представляет собой 4 предварительно обученных модели с разным количеством параметров: 350M, 2B, 6B, 16B. Если у вас под рукой компьютер с хорошей видеокартой на 16 Гб видеопамяти, то можно выбрать вариант с 2B. На меньшем количестве VRAM можно попробовать вариант 350M. Совсем недавно о своём опыте использования CodeGen рассказал один из пользователей Хабра.

В обозримом будущем можно обратить внимание на хитрую утилиту FlexGen, позволяющую запускать большие языковые модели на системах с недостаточным количеством видеопамяти. Их дорожная карта указывает, что в будущем разработчики добавят поддержку моделей CodeGen, а также ускорителей ANE (Apple Neural Engine), встроенных в процессоры Apple Silicone.

Митапы

Онлайн

Python meetup

29 марта 2023

Совсем скоро состоится весенний Python Meetup. Вас ждут три отличных доклада:

Андрей Скиба из Uchi.ru поделится опытом работы со сложными метриками. Вместо дорогих коммерческих решений они пошли по пути написания собственной легковесной системы.
Шарыпов Алексей из VK раскроет подробности создания небольшого проекта на FastAPI c использованием Poetry от начала до production-ready образа. Все вкусные подробности, вроде настройки линтеров и тестов, присутствуют.
Алексей Каньков из Revizto посвятит доклад функциональному программированию на Python. Эта парадигма не только помогает управлять параллелизмом, но и упрощает тестирование, а также сводит к минимуму побочные эффекты.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Управление зависимостями и устройствами

Evrone digest — Mon, 06 Feb 2023 11:30:11 +0000

Сегодня разберёмся с консервативным подходом к управлению зависимостями, порулим сетевыми устройствами Mikrotik и погрузимся в историю создания CircuitPython для программирования микроконтроллеров. Приятного чтения!

Скучный Python — зависимости

В мае 2022 года разработчик из Калифорнии James Bennett рассказал свой подход к управлению зависимостями в статье «Boring Python: dependency management». В его представлении термин «скучный Python» это не характеристика языка, а набор рекомендаций по уменьшению количества багов, «нескучных сюрпризов». Полностью от них избавиться нереально. Можно лишь снизить их число, убрав потенциальные источники ошибок.

Во многом его советы сводятся к исключению экспериментов и использованию стандартного инструментария там, где это возможно. Штатная экосистема пакетов Python насчитывает три инструмента: setuptools, pip и venv. Они неспешно развивались более 10 лет и доказали свою надёжность. По мнению автора, не стоит пытаться искать и использовать альтернативы, поскольку в дальнейшем это станет источником проблем.

Если речь заходит о системе управления пакетами pip, то имеет смысл задуматься, как передавать туда имена устанавливаемых пакетов. Это может быть или список имён в командной строке или сформированный файл(ы) с требованиями. Второй вариант удобнее и помогает формированию переносимой среды.

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

Не пренебрегайте виртуальными средами, «virtual environments». Это гарантирует изоляцию интерпретатора Python и всех установленных пакетов. Таким образом можно иметь сразу несколько независимых друг от друга сред разработки. Всё это путь к максимально воспроизводимой и согласованной среде. Её будет легко перенести и развернуть на любой инфраструктуре.

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

Paramiko для MikroTik

Латвийская компания MikroTik хорошо известна всем сетевым инженерам. Устройства, разрабатываемые этой компанией, работают как дома и в небольших офисах, так и в крупных дата-центрах. Если говорить о маршрутизаторах, то они работают на операционной системе RouterOS. Поддерживается множество способов управления — от консольного доступа через SSH/Telnet до использования Webfig/WinBox. Разработчикам также доступен вариант управления через API. Это позволяет создавать кастомные приложения, способные собирать показания с сетевых устройств и управлять ими.

Сама MikroTik в качестве референса указывает возможность взаимодействия без сторонних библиотек. Но для простых задач подойдёт и инструмент Paramiko, представляющий собой имплементацию протокола SSHv2. После установки можно сразу накидать простой код, вроде такого:

import paramiko # Подключимся к маршрутизатору ssh = paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect("<IP-ADDRESS>", username="<USERNAME>", password="<PASSWORD>") # Для примера выполним команду вывода IP-адреса stdin, stdout, stderr = ssh.exec_command("/ip/address/print") # Выведем результат print(stdout.read().decode()) # Закроем SSH-соединение ssh.close()

Заменяем <IP-ADDRESS>, <USERNAME> и <PASSWORD> на действительные значения и можно тестировать. Это лишь самый примитивный пример применения.

Сценарий использования в дата-центре может выглядеть следующим образом. Сетевое оборудование чаще всего учитывается в системе DCIM (Data center infrastructure management). Опытному разработчику ничего не стоит выгрузить реестр с оборудованием из DCIM, а затем выполнить выполнить нужные действия сразу на группе маршрутизаторов. Так, например, можно выполнить обновление программного обеспечения, бэкап или восстановление файлов конфигурации.

CircuitPython от Adafruit

Прошло 10 лет с того момента, как Эрнандо Барраган (Hernando Barragán) решил в качестве магистерской диссертации создать дешевую и простую среду для начального обучения программированию. Результатом стала платформа Wiring, форк которой мы знаем под названием Arduino.

С ростом популярности платформы Arduino стали появляться компании, разрабатывающие совместимые модули расширения. Эти модули значительно снижают порог входа в разработку, так как включают в себя всю необходимую обвязку. То есть пользователи не должны паять, а просто подключают модули и начинают программировать. Компании вроде Adafruit Industries предлагают сенсоры, дисплеи, драйверы для двигателей, а также другие модули расширения.

Разработка качественного железа стала одним из факторов успеха. Но без создания приложений и формирования экосистемы компания вряд ли бы достигла текущих показателей. Инженеры Adafruit пошли дальше и решили ещё упростить программирование микроконтроллеров, сделав ставку на внедрение Python. Проблема была лишь в том, что применяемые чипы обладали весьма скромными характеристиками. Это значило, что поддерживать все фичи языка было бы нереальной задачей.

Конечно, Adafruit не единственные, кому в голову пришла идея создать Python для микроконтроллеров. В 2013 году успешная краудфандинговая кампания австралийского разработчика Дэмиена Джорджа (Damien George) позволила создать такую версию, названную MicroPython. Adafruit решили не изобретать велосипед, а взять этот код за основу уже собственного продукта CircuitPython.

Из оригинала были удалены прерывания и многопоточность. Параллелизм поддерживается весьма условно. Async/await доступны лишь на некоторых платах, а для решения типовых задач, вроде воспроизведения музыки, были созданы отдельные программные модули. Чтобы в результате жесткого сбоя пользователь не получил «кирпич», был добавлен специальный безопасный режим, позволяющий пропустить запуск пользовательского кода. Если приложение вызвало сбой, плата остается доступной.

CircuitPython отлично задокументирован, поддерживает более 300 устройств и даёт возможность пробросить код на Python в «реальный мир». Если у вас завалялся поддерживаемый микроконтроллер без дела, то в него можно вдохнуть жизнь с помощью любимого языка программирования.

Митапы

Онлайн

Python meetup

29 марта 2023

Рады сообщить, что у нас запланирован весенний Python Meetup. Программа мероприятия формируется. Подать заявку на участие спикера можно до 10 марта. Детальная информация будет опубликована позже, следите за нашими новостями.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Быть начеку

Evrone digest — Tue, 10 Jan 2023 07:08:24 +0000

В нашем сегодняшнем дайджесте вы узнаете, как при обычном использовании PyPI поймать зловред. Ещё мы расскажем о ресурсе, собравшем нетривиальные примеры кода, подведём итоги 2022 года для urllib3 и выясним, как добавить настоящей песочнице интерактивности.

Предновогодняя атака на PyTorch

Рождество и Новый год прекрасные праздники, но как раз в это время активизируются злоумышленники, рассчитывая на сниженное внимание и уменьшение контроля. Пока некоторые разработчики и DevOps-инженеры мысленно уже начинали открывать напитки и выбирать себе подарки, фреймворк PyTorch подвергся атаке на цепочки поставок.

Тот, кто спланировал атаку хорошо знал особенности PyPI. Вредоносный пакет torchtriton был загружен с тем же именем, которое использует PyTorch nightly. Система проиндексировала его и дала больший приоритет, чем легитимному пакету. Таким образом все, кто загрузил PyTorch-nightly в Linux через pip в период с 25 декабря 2022 г. по 30 декабря 2022 г., получили в нагрузку вредоносный бинарник triton. Зловред ворует данные и загружает на подконтрольный сервер. Такая атака была давным-давно предсказана и досконально описана в Issue #5045 и Issue #8606. Но логика работы PyPI осталась неизменной.

Чтобы проверить, был ли ваш сервер скомпрометирован, выполните команду:

python3 -c "import pathlib;import importlib.util;s=importlib.util.find_spec('triton'); affected=any(x.name == 'triton' for x in (pathlib.Path(s.submodule_search_locations[0] if s is not None else '/' ) / 'runtime').glob('*'));print('You are {}affected'.format('' if affected else 'not '))"

В блоге PyTorch указан хэш вредоносного бинарника и данные о его поведении:

SHA256(triton)= 2385b29489cd9e35f92c072780f903ae2e517ed422eae67246ae50a5cc738a0e

С того момента, как вредоносный код был обнаружен, пакет с «сюрпризом» загрузили примерно 3 тысячи раз. Но за то же время стабильный билд PyTorch загрузили 1.5 млн раз, значит, атака была не масштабной? Даже от такой скромной ущерб может быть существенным.

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

Не верь глазам своим

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

Помощником в этом может стать проект wtfpython, доступный как на английском, так и частично на русском языке. Этот мануал даже доступен в виде устанавливаемого пакета PyPI:

$ pip install wtfpython -U $ wtfpython

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

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

В ожидании urllib3 v2

Стандартная библиотека Python хороша, но всё же лишена многих нужных функций. Если вам потребовалось использовать удобный и потокобезопасный HTTP-клиент, то скорее всего возьмёте urllib3 или requests. Пакет urllib3 настолько популярен, что в сутки скачивается более 10 млн раз, а за 2022 год количество загрузок превысило 3 млрд раз.

Такие крупные Open-source проекты требуют кропотливого труда множества людей. Делать это на чистом энтузиазме, разумеется, невозможно. Добровольные пожертвования на проект в 2022 году составили $26 615. Наибольший спонсорский взнос в размере $13 000 был сделан фондом Spotify FOSS. Из собранных средств $6 500 были распределены между мейнтейнерами и участниками сообщества. $18 827 остаются на открытом коллективном балансе проекта и будут использованы для будущего развития urllib3.

В ноябре 2022 года вышел urllib3 v2.0.0a1. Кодовую базу оптимизировали для Python 3.7+, удалили поддержку старых версий. Полный список изменений есть в репозитории проекта на GitHub.

Важнейшей задачей при разработке второй версии было сохранение 99% обратной совместимости. Обновление не должно вызвать никаких проблем у большинства пользователей. Надеемся, что у разработчиков это получится и мы увидим релиз v2.0.0 в первой половине 2023 года.

Интерактивная карта на песке

Вернёмся на 13 лет назад. Microsoft представила Project Natal, более известный как Kinect. Революционный игровой контроллер, считывающий в трехмерном пространстве движения и позы игрока. В его основе два датчика глубины и цветная камера. Вместе они позволяют получать и изображения, и карты глубины. Первая версия контроллера обладала низкой точностью и разрешением, что существенно улучшилось в следующей версии. Увы, но добиться достаточной точности в играх так и не удалось, что и послужило причиной снятия с производства в 2017 году.

Но это вовсе не поставило крест на альтернативном использовании Kinect. Что только не делали на его основе — от музыкального инструмента и диджейского пульта до 3D-сканера (что оказалось в 200 раз дешевле промышленного устройства). Там, где не требовалась высокая скорость движений, Kinect прекрасно справлялся с построением карт глубин и это привлекло к нему интерес множества разработчиков, в том числе и военных.

Когда мы говорим слово «песочница», то чаще всего используем его в переносном смысле. Если объединить настоящую песочницу, проектор и Kinect, получится проект Magic-Sand, настоящий бриллиант мира дополненной реальности. Его часто демонстрируют на выставках и публичных мероприятиях.

Magic-Sand песочница на выставке CSEO Apollo-Artemis

Казалось бы, забавная игрушка, красивая демонстрация, не более. Но на её базе создали вполне серьёзную систему планирования с учётом особенностей рельефа. Проект CombatViewer объединяет опыт Magic-Sand со слоем карты, а также лазерной указкой для перетаскивания объектов.

Демонстрация перемещения объектов по песочнице лазерной указкой

В качестве стека использовался Python вместе с библиотекой машинного зрения OpenCV и интерфейсом на Tkinter. Автор проекта опубликовал небольшую статью на Medium, а готовая версия в настоящий момент активно используется в Бразилии.

Митапы

Онлайн

Python meetup

29 марта 2023

Рады сообщить, что у нас запланирован весенний Python Meetup. Программа мероприятия формируется. Детальная информация будет опубликована позже, следите за нашими новостями.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Многострадальный релиз

Evrone digest — Thu, 08 Dec 2022 13:58:50 +0000

Эпопея завершилась и Python 3.11 вышел в релиз. Предлагаем заварить чайку и похоливарить на тему стилей, принципов и нотаций именования переменных. На связи Evrone, мы рады говорить с вами на одном языке.

Ключевые изменения

Ещё не успел остыть свежеиспечённый релиз Python, как в чатах разработчиков посыпались шутки о том, что следующая версия должна называться Python NT Workstation. Но шутки-шутками, а Python 3.11 for Workgroups получился весьма интересным. Путь к релизу был тернистым и включал в себя 5 beta-версий и сдвиг срока релиза. Благо всё это позади, и мы можем взглянуть на результат.

Эталонный интерпретатор CPython стал быстрее. Прирост составил от 10% до 60% по сравнению с предыдущей версией 3.10. В качестве средней цифры разработчики называют 25%. Публичные результаты бенчмарков опубликованы на Github. В качестве небольшого спойлера — там же вы найдёте и результаты альфа-версии 3.12.0a0.

Добавили группировку и одновременное использование нескольких несвязанных исключений. Реализовано это с помощью типов ExceptionGroup и BaseExceptionGroup. Оператор except также получил синтаксис, позволяющий управлять этими группами. Вдобавок исключения теперь можно снабжать заметками через метод add_note().

Стандартная библиотека пополнилась модулем для парсинга TOML-файлов tomllib. Этот формат появился давно, ещё 9 лет назад, и с тех пор хорошо зарекомендовал себя для хранения настроек в различных приложениях. Разумеется, это не единственные изменения, но наиболее значимые. Познакомиться с оставшимися можно в официальной документации.

EAFP против LBYL

Зубодробительные аббревиатуры наше всё. Но если WYSIWYG знает каждый, то аббревиатуры EAFP и LBYL многие слышат впервые. Первое переводится, как Easier to Ask for Forgiveness than Permission (проще просить прощения, чем разрешения). Применительно к программированию этот принцип означает, что можно писать любой код и ожидать, что он будет работать как положено. Если на каком-то этапе возникает исключение, то его нужно обработать соответствующим образом.

Полной противоположностью EAFP является принцип LBYL — Look Before You Leap (посмотри, прежде чем прыгать). Используя этот принцип, следует вначале удостовериться, что решение сработает и лишь потом писать код. Такой подход более применим для других языков программирования, таких как C/C++, где возникновение исключения — ситуация действительно исключительная. Для Python она таковой не будет.

Прекрасная демонстрация есть на StackOverflow.

EAFP:

try: x = my_dict["key"] except KeyError: # handle missing key

Мы пробуем присвоить переменной значение ключа, выполнив поиск в словаре. Если что-то пошло не так — выбрасываем исключение. Ключ ищется только один раз.

LBYL:

if "key" in my_dict: x = my_dict["key"] else: # handle missing key

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

Если начать сравнивать оба этих принципа, то может возникнуть ощущение, что EAFP может обойтись «слишком дорого» и снизит производительность. Отчасти это правда, но каждая новая реализация интерпретатора «снижает стоимость» использования исключений.

В сухом остатке можно сделать простой вывод о том, что EAFP отлично подходит для Python. Разумеется, это не исключает того, что выбор остаётся исключительно за разработчиком.

Нотации именования

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

Pascal case требует имена переменных начинать с заглавной буквы, например, Name. Если имя содержит несколько слов, то все они должны начинаться с заглавной буквы. Пример — FirstName.
Camel case (верблюжья нотация) очень похожа на Pascal case, но есть одно кардинальное отличие. Односложные имена начинаются со строчной буквы, например, name. Если имя содержит несколько слов, то первая буква строчная, а все последующие заглавные. Пример — firstName.
Snake case (змеиная нотация). Все имена начинаются со строчных букв. В качестве разделителя используется нижний пробел. Пример — first_name.
Kebab case (шашлычная нотация) такая же, как и Snake case, но в качестве разделителя используется дефис. Пример — first-name.
Hungarian notation (венгерская нотация) отличается от всех. Имя любой переменной предваряется заранее определёнными префиксами. Строгих правил у этой нотации нет — префикс может быть из одного или нескольких символов. При этом она может мимикрировать под другие нотации. Примеры — pFirstName, pfirst_name, pfirst-name.

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

В Python — это Snake Case для функций и переменных, а также Pascal Case для классов, что зафиксировано в PEP8. Это руководство по стилю позволяет избежать множества неприятных ситуаций и рекомендуется к соблюдению авторами языка.

Интересно посмотреть

Пропустили наш предыдущий Python-митап? Не беда! Все доклады есть на нашем YouTube-канале в 4K.

Теперь следить за митапами Evrone стало удобнее. В Telegram-канале Evrone meetups мы выкладываем анонсы с подробными описаниями докладов, а также студийные записи после мероприятий. А ещё у нас можно выступить, мы поможем оформить вашу экспертизу в яркое выступление. Подписывайтесь и пишите @andrew_aquariuss, чтобы узнать подробности.

Вакансии

Удаленка / Офис

Evrone

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

Подробнее

Польза и вред кастомизации

Evrone digest — Wed, 09 Nov 2022 12:38:09 +0000

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

Custom exceptions

Задумайтесь — а нужны ли вообще пользовательские исключения? С одной стороны, в Python есть обилие встроенных исключений «‎на все случаи жизни». А с другой, хорошим вариантом будет говорить, где конкретно ошибка в приложении, а не просто указывать на большой кусок кода.

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

Создать пользовательское исключение легко — объявляем класс, являющийся наследником от встроенного Exception.

>>> class PredictionError(Exception): ... pass

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

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

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

Разумеется, это лишь идеи, конкретное воплощение которых раскрывает статья Should we use custom exceptions in Python?. Там есть примеры кода и детальное объяснение каждого из описываемых решений.

Собственные расширения Python

Продолжаем тему кастомизации, сейчас расскажем о расширениях.

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

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

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

Это ведь тоже компромисс. Если делать расширение на Rust, то придётся смириться с тем, что у него более сложный синтаксис и статическая типизация. Если возьмёте Cython с привычной динамической типизацией и пропустите какой-либо тип переменной, то производительность может резко упасть, а в чём тогда смысл?

Тем не менее, когда вы точно понимаете где находится bottleneck вашего кода, усилия по написанию собственного расширения будут оправданы. Это может улучшить производительность. Напоследок советуем прочитать туториал от RealPython про создание собственных расширений на С и статью Nine Rules for Writing Python Extensions in Rust.

Распознавание речи с OpenAI Whisper

Американская компания OpenAI, одним из основателей которой является Илон Маск, в конце сентября этого года сделала важный вклад в развитие открытого программного обеспечения. они выложили в общий доступ система распознавания речи (ASR) Whisper. Сердце системы — натренированная на 680 000 часов речи нейронная сеть, которая по словам разработчиков приблизилась к человеческому уровню распознавания.

Разумеется, нейронная сеть «‎заточена» на английский язык. Но это вовсе не значит, что она бесполезна для распознавания русского языка. Некоторые исследовательские проекты уже провели эксперименты на примере видеозаписей с российского ТВ.

Эта нейронная сеть содержит 1.6 миллиарда параметров и способна выполнять перевод с 97 языков мира. Вместе с качественными и специальным образом подготовленными данными для обучения, разработчики задействовали приличное количество зашумлённых и не слишком качественных записей. В итоге это позволило существенно улучшить показатели нейросети.

Такая система отлично подойдёт для получения расшифровки подкастов, докладов и конференций. Её можно применять в качестве основы для создания новых приложений с распознаванием речи, систем «‎умный дом» и интерактивных голосовых меню (IVR).

JIT-компилятор для Numpy

В наших дайджестах мы затрагивали тему JIT-компиляторов для Python, таких как Pyjion. Сегодня расскажем ещё об одном инструменте, позволяющем значительно ускорить обработку данных библиотекой NumPy. Это JIT-компилятор Numba, разрабатываемый при поддержке гигантов Intel, AMD и NVIDIA.

Основная идея — выполнять преобразование отдельных функций, написанных на Python, в быстрый и оптимизированный машинный код с помощью LLVM. При этом разработчику не надо особо задумываться — достаточно обернуть нужную функцию декоратором, а Numba сделает всю остальную работу.

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

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

Отдельно отметим, что Numba позволяет задействовать технологию CUDA и исполнять разогнанный код непосредственно на графических процессорах Nvidia. При правильном применении это сделает ваш Python-код потрясающе быстрым.

Интересно посмотреть

Пропустили наш предыдущий Python-митап? Не беда! Все доклады есть на нашем YouTube-канале в 4K.

Алексей Шарыпов из VK рассказал, как они писали сервис для тестирования «‎черного ящика» (приложения без тестов и документации), написанном на малоизвестном языке:

Савостьянов Дмитрий из Nordcurrent поделился опытом работы с необычным контентом, а именно записями игры в Dota 2. Как парсить реплеи матчей и записи стримов на YouTube и находить хайлайты при помощи специально обученных нейросетей BERT и TrOCR:

Денис Аникин из Райффайзенбанка разложил по полочкам мысли о том, куда движется Python. Когда и зачем он ускоряется, NoGIL, Сinder и прочих нововведениях:

Вакансии

Удаленка / Офис

Evrone

Подробнее