Питонические атаки

Летом успел съездить на PyCon Russia и выступить с докладом про новый язык программирования Mojo. История там такая: Крис Латнер, некогда очень активно поучаствовавший в создании LLVM, clang и Swift, вместе со своей командой решил сделать платформу для обучения нейросеточек и другого ML, а для этого делает свой язык программирования, максимально похожий на питон и тесно интегрированный с ним. Анонс языка был очень мощным: вышло несколько статей, буквально пророчащих смерть обычного питона и становление Mojo в качестве его замены. Мне, разумеется, захотелось разобраться, насколько это серьёзные заявления, а насколько — хайп и кликбейт. Разобрался! А теперь и вы можете: https://youtu.be/kzNwVdA3t_s. P. S. А буквально позавчера Mojo стало можно загрузить и попробовать локально, ура: https://www.modular.com/blog/mojo-its-finally-here

Выяснил отсюда, что math.fsum() всё-таки нужна, потому что она лучше сохраняет точность, чем встроенная sum(), хоть и работает значительно медленнее. Видимо, там какие-то более сложные алгоритмы используются.

Ещё один прикол в 3.12 — встроенная функция sum() теперь использует специальный алгоритм для сложения чисел с плавающей точкой с минимальной потерей точности (прочитать про алгоритм можно на вики). Раньше было как, складываешь 10 чиселок, где в результате ожидаешь получить 1, но получаешь что-то немного другое:

>>> sum([0.1] * 10)
0.9999999999999999

И ладно бы оно просто всегда ошибалось одинаково, дак ведь погрешность ещё и зависит от порядка, в котором складывать числа:

>>> sum([0.1] * 5 + [0.05] * 10)
1.0000000000000004
>>> sum([0.05] * 10 + [0.1] * 5)
0.9999999999999999
>>> sum([0.1, 0.05, 0.05, 0.05, 0.05, 0.1, 0.1, 0.05, 0.05, 0.1, 0.05, 0.05, 0.05, 0.1, 0.05])
1.0000000000000002

А вы разве не знали, что сложение float'ов не коммутативно? Но была специальная функция math.fsum(), которая всё делает правильно:

>>> math.fsum([0.1] * 10)
1.0
>>> math.fsum([0.1] * 5 + [0.05] * 10)
1.0
>>> math.fsum([0.05] * 10 + [0.1] * 5)
1.0

Дак вот в 3.12 встроенная функция sum() даёт такие же результаты, как math.fsum(). По крайней мере, я не смог найти примера, где они дали бы разный результат. Кроме того, по моим замерам, sum() работает ещё и раза в полтора быстрее math.fsum():

>>> timeit.timeit("sum([0.05] * 10 + [0.1] * 5)")
0.26875441599986516
>>> timeit.timeit("math.fsum([0.05] * 10 + [0.1] * 5)", setup="import math")
0.34194887499961624

Кто-нибудь понимает, зачем теперь нужна math.fsum()?

Судя по опросу выше, для многих релиз 3.12 не содержит каких-то больших сносящих крышу фич. Сложно с этим поспорить. Что ж, давайте тогда смотреть на мелкие фичи. По мелочам много всего приятно поменялось. Например, в itertools добавили функцию batched, которая разбивает список или любой итерируемый объект на кортежи указанной длины. Последний кортеж может быть короче указанной длины, если не хватит элементов. Пример: >>> list(batched('ABCDEFG', 3)) [('A', 'B', 'C'), ('D', 'E', 'F'), ('G',)] Раньше для этого приходилось либо определять эту функцию самостоятельно, взяв её из документации Python, либо устанавливать библиотеки, типа more-itertools. Да, эта функция испокон веков лежит в виде сниппета кода в документации, но в стандартной библиотеке её нигде не было. Теперь есть 🤷‍♂️ Возможно, теперь я буду чуть реже ставить more-itertools. Документация: https://docs.python.org/3/library/itertools.html#itertools.batched

PSF и JetBrains выложили результаты опроса среди питонистов за 2022 год: https://lp.jetbrains.com/python-developers-survey-2022/ По результатам вижу несколько интересных пунктов: 🔹 Значительно увеличилась доля тех, кто считает себя Data Scientist'ом — 34% против 29% в прошлом году; и этот опрос ещё проходил до или в самом начале нынешней GPT-лихорадки; интересно будет посмотреть на результаты следующего года. 🔹 Среди сценариев использования Machine Learning обогнал девопсов и сисадминов, а доля веб-девелоперов почему-то снижается. Баланс сил нарушен — раньше веб-разработка и data science/machine learning были примерно в одинаковых пропорциях. 🔹 Чёрт побери, почему доля Python 2 выросла? Всё же хорошо шло, вы зачем раскопали-то опять. Это как-то связано с предыдущими пунктами? 🤔 🔹 Доля Poetry среди пакетных менеджеров постепенно растёт. Люди постепенно пересаживаются с Requests на httpx. FastAPI надёжно закрепился в тройке популярных веб-вреймворков и продолжает откусывать доли у Flask и Django.

Pydantic нанимает фронтендера. Что-то происходит 🤔 Видать начали что-то делать из своего роадмапа. Twi

О, пошло дело. В репозитории python/cpython на гитхабе появился тэг v3.12.0, что означает... Ну, думаю, вы и сами понимаете. Скоро будет официально релизнуто. 🍾 Правда, в этот раз как-то скромно. Без помпезных стримов со спикерами и шляпами. Или это я просто не нашел где стримят?

Офигеть, уже вышел Python 3.12.0rc2. Это последняя предрелизная версия. Дальше уже только настоящий релиз, который запланирован на 2 октября. Как правило, между вторым релиз-кандидатом и релизом почти ничего не меняется, так что, в принципе, уже можно с нежной осторожностью трогать свежую версию интерпретатора. Вот здесь можно почитать What’s new.

Apple рассказывает про часы — точно такие же, как старые, только новее и розовее. А тем временем без больших презентаций происходят куда более интересные вещи. Например, в Ruff появился встроенный форматтер. Пока что это только экспериментальная альфа-версия, но уже обещают 99% совместимость с Black. Уже можно поставить последнюю версию Ruff и попробовать. Позже в этом году планируется уже пригодный к продакшн использованию релиз.

Появился PEP 723, который предлагает "встраивать" pyproject.toml в однофайловые скрипты. Предлагается добавить переменную __pyproject__, которая будет содержать в себе валидный TOML, описывающий метадату скрипта, в том числе как скрипт запускать и какие зависимости необходимы для запуска. К примеру, вот так будет выглядеть скрипт, которому для работы нужна библиотека requests и питон 3.11 или выше:

__pyproject__ = """
[project]
requires-python = ">=3.11"
dependencies = [
  "requests<3",
]
"""
import requests
resp = requests.get("https://peps.python.org/api/peps.json")
print(resp.json())

PEP прикольный, что-то такое есть в качестве экспериментального RFC в Rust. Из минусов хотел бы отметить то, что автоматическая установка зависимостей может привести к запуску нежелательного кода. Но решение банальное - перед тем как что-то запускать, проверяйте, что вы запускаете. #pep

Ещё одна новость про JetBrains, но вот это уже настоящая революция, а не эти ваши ИИ попсовые. Наконец-то в PyCharm добавляют встроенную поддержку форматтера black! 🎉 Прямо без каких-либо плагинов, IDE задетектит наличие black в виртуальном окружении и предложит использовать его вместо дефолтного форматтера пайчарма. Настройки подхватывает из pyproject.toml. И всё, просто берёт и форматирует! Правда, заметил, что люди жалуются на модальное окошко, которое выскакивает на мгновение в процессе форматирования. Ещё пока что нет поддержки blackd, который использовали для ускорения форматирования, но это обещали добавить. Короче, не идеально, но для начала хорошо. Доступно только в EAP, а по-настоящему опубликуют в версии 2023.2. https://blog.jetbrains.com/pycharm/2023/07/2023-2-eap-5/ #jetbrains

JetBrains добавили в свои IDE ИИ ассистента Есть режим чата, возможность копипастить сниппеты кода в чат и обратно в редактор, возможность генерить документацию, сообщения для коммитов и придумывать имена переменным. Под капотом сейчас происходят вызовы в OpenAI, а ещё есть несколько моделей поменьше от JetBrains. В будущем хотят интегрировать ещё каких-то провайдеров языковых моделей. Выделяешь кусок самого мутного кода в проекте, нажимаешь хоткей Alt/Option+Enter > AI Actions > Explain code, тут же открывается чат, где заботливый ИИ на чистейшем английском объясняет тебе суть. Правда, видимо, я выбирал слишком мутные куски кода, поэтому мне не особо помогло. Всё равно понравилось. Пока что доступно только в EAP-сборках всех IDE на основе IntelliJ IDEA. В будущем фича наверняка станет платной (конечно, счета от OpenAI сами себя не оплатят). Не работает на территории РФ. В прочем, не думаю, что это вызовет у вас какие-то затруднения. https://blog.jetbrains.com/idea/2023/06/ai-assistant-in-jetbrains-ides/ #jetbrains

Но как вы объясните вот это? Разве бывает FastAPI без Starlette?

Я вам говорю, скоро он их обоих подожмёт

Популярность имеет свои минусы. Чем популярней язык программирования, тем выше его распространённость, а значит найдутся те кто поспешит воспользоваться этим. С ростом популярности Python всё больше на PyPi появляется вредоносных пакетов. Трояны, стиллеры и доставщики более опасных вредоносов. Команда PyPi постоянно мониторит подобные случаи но и их возможности достигли предела. В результате сервис временно закрывает возможность заливки новых пакетов и регистрации юзеров. PyPI new user and new project registrations temporarily suspended Возможно одной из причин большого наплыва вредоносов является резко возросшая доступность их создания. Сегодня любой, даже не программист, может попросить у ChatGPT написать необходимый код и все инструкции для атаки. Основной тип атаки - рассчёт на опечатку в названии пакета. Если невнимательный программист случайно установит pilow или djangoo, считай что вредонос уже в системе. Чтобы избежать подобных факапов я рекомендую: ▫️ Всегда работайте в виртуальном окружении, неизвестные проекты устанавливайте внутри контейнеров. ▫️ Используйте файл requirements.txt вместо ручной установки пакетов ▫️ Очень внимательно пишите названия пакетов, а после написания проверьте еще раз. Сверьте с названием из документации. ▫️ После успешных тестов всегда фиксируйте версию пакета. Бывали случаи когда опасный код добавляли в новые версии. К тому же и без этой опасности не рекомендуется ставить по умолчанию последнюю версию. ▫️ Используйте вспомогательные инструменты для проверки безопасности, например https://pyup.io/safety или https://github.com/PyCQA/bandit. Они помогут не только найти опасный код в чужих пакетах, но и ваш код проверит на уязвимости. Будем надеяться что PyPi переосмыслит методы борьбы с вредоносами, например внедрит ИИ для проверки как симметричный шаг. #offtop

В AWS Lambda наконец-то добавили рантайм Python 3.10. Вот интересно, они специально зачем-то добавляют новые рантаймы с отставанием в полтора года? Впрочем, все, кто серьёзно занимается разработкой serverless-приложений, наверняка просто используют контейнеры с каким нужно питоном внутри. Тем временем в Yandex Cloud есть рантайм с Python 3.11. Но почему-то нет 3.10 🤔

В Python 3.12 приняли PEP 695 – Type Parameter Syntax, который добавляет новый синтаксис для дженерик классов, функций и алиасов для типов. Это вот то, где используется typing.TypeVar (спойлер: больше нет). Да, это снова про тайп хинты. Похоже, это самая активно развивающаяся область языка за последние 10 лет. Давайте посмотрим на изменение на примере функции с переменными типа (смотри скриншот 1). Если что, это нужно для того, чтобы связать типы нескольких параметров и возвращаемых значений функции. Вот функция принимает на вход значение (любого типа), а на выходе она отдаст значение такого же типа. Часто используемый сценарий, как мне кажется. Такое стало писать намного приятнее. Не нужно отдельно писать это явное, некрасивое определение typing.TypeVar, где ты дважды пишешь одно и то же имя переменной и засоряешь странными однобуквенными именами глобальную область видимости. В 3.12 можно будет просто прям при определении функции задекларировать своё намерение: "я буду тут использовать переменную типа T", и аннотируешь ей все связанные аргументы и возвращаемые значения. Офигенно? О да. Кроме того, тайп-алиасы с переменными типов тоже стало писать намного легче (смотри скриншот 2). Тоже отпала необходимость явно определять TypeVar. Но теперь в языке появляется новое "мягкое" ключевое слово type, которое ведёт себя по-разному в зависимости от контекста (как async). Забавно, что это нововведение фактически депрекейтит PEP 613 про тайп алиасы, который появился в 3.10. Я даже толком не успел начать им пользоваться. Всё так быстро меняется. Про классы-дженерики писать не буду, но если вы такое практикуете, то сходите почитайте док. Там интересно. Отдельно прикольно, что больше не надо думать о ковариантности, контравариантности и инвариантности переменных типов. Эти концепции никуда не уходят, но теперь тайп-чекер будет сам понимать, с чем он работает, без необходимости явного указания. Это вот та штука, из-за которой приходится аргументы функций аннотировать как Sequence[Parent] вместо list[Parent] и которую я долго не мог осознать. Кстати, недавно смотрел хороший видос про эти концепции. Разобрался, вроде. Блин, не может ли недостаток понятных материалов на эту тему быть связан с тем, что эти слова так сложно писать и произносить? Я минуту набирал и перечитывал эти три слова в начале абзаца, да и то наверняка ошибся. Если не думать о том, что это изменение создаёт новую область видимости для имён (scope) с довольно странной механикой работы, добавляет новое мягкое ключевое слово, добавляет новый сорт TypeVar (теперь у нас есть "традиционные" и новые, и их нельзя смешивать между собой) и в целом делает язык синтаксически сложнее (давайте писать квадратные скобки вообще везде), то это абсолютно точно движение в правильную сторону, шаг навстречу программисту. Бойлерплейта станет меньше, импортов из typing меньше, сложных концепций меньше, пространства для ошибки тоже. Да и выглядит относительно предыдущего варианта намного приятнее. Мне нравится.