#prog #rust #python #article

The easiest way to speed up Python with Rust

Статья про rustimport — библиотеку для лёгкой интеграции Rust-кода в код на Python, позволяющая импортировать отдельные rs-файлы как расширения. Со стороны Python требует лишь установить import hook.

Отдельно отмечается, что применение у этого метода скорее для прототипирования — по мере роста объёма кода на Rust преимущества rustimport становятся менее полезными.

#prog #python #amazingopensource

Ruff

An extremely fast Python linter, written in Rust.

⚡️ 10-100x faster than existing linters
🐍 Installable via pip
🛠 pyproject.toml support
🤝 Python 3.11 compatibility
📦 Built-in caching, to avoid re-analyzing unchanged files
🔧 Autofix support, for automatic error correction (e.g., automatically remove unused imports)
📏 Over 500 built-in rules
⚖️ Near-parity with the built-in Flake8 rule set
🔌 Native re-implementations of dozens of Flake8 plugins, like flake8-bugbear
⌨️ First-party editor integrations for VS Code and more
🌎 Monorepo-friendly, with hierarchical and cascading configuration

<...>

> Ruff is so fast that sometimes I add an intentional bug in the code just to confirm it's actually running and checking the code.

#prog #python #c #abnormalprogramming #article

Writing a C compiler in 500 lines of Python

С небольшим нюансом: компиляция в WASM и, понятное дело, только весьма небольшого подмножества C. Ну и для достижения ограничения на количество строк компилятор однопроходной.

#prog #rust #python #performancetrap #article

Rust-Python FFI

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

Внезапный #python

#prog #cpp #python #meme изобличающий

#prog #rust #python #article #suckassstory #performancetrap

Rust std fs slower than Python!? No, it's hardware!

Редкий случай, когда удалось отследить баг и подтвердить, что он действительно в железе. Ссылки на патчи в glibc прилагаются.

TL;DR: оба варианта кода используют mmap в качестве буфера для считывания из файла, но в Python этот буфер используется с некоторым смещением. На некоторых процессорах — в том числе в том, который используется на машине автора — команда rep movsb — которая использовалась в реализации memcpy — парадоксальным образом работает на порядок более медленно при работе с выровненным буфером.

#prog #python #article #suckassstory

node.example.com Is An IP Address

Или про проблему с tipchikami в Python2

#prog #python #article

ABI compatibility in Python: How hard could it be?

Нативные расширения для Python могут распространяться в двух формах: в исходниках и в пресобранных бинарях.

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

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

Для того, чтобы облегчить жизнь и пользователям, и разработчикам, разработчики CPython предоставили ручки, позволяющие выставлять разработчикам нативных расширений стабильное API со стабильным ABI. С технической точки зрения это выражается в установке макроса Py_LIMITED_API в значение конкретной версии API перед включением заголовочных файлов, предоставляющих интерфейс к CPython. Это стабильное ABI называется abi3, и пакет с нативным расширением может иметь тег, говорящий, что код собран относительно этого ABI конкретной версии.

У этого подхода, однако, есть гигантский недостаток: никакой инструмент цепочки упаковки пакета, его распространения и использования — включая сам CPython — не проверяет, что тег abi3 и конкретная версия выставлены корректно. Иными словами, ничто не останавливает пользователей от того, чтобы подгрузить к интерпретатору расширение с некорректным ABI. Последствия этого также плачевны, как и при любом несовпадении ABI, и могут варьироваться от (при удаче) отсутствия каких-либо проблем до крашей или, что гораздо хуже, порчи памяти.

В Trail of bits разработали инструмент, который как раз и проверяет, насколько расширение, заявленное, как поддерживающее abi3, действительно является таковым. Для исследования того, насколько этот инструмент полезен, авторы статьи проверили пакеты, скаченные с PyPI за последние 21 день (на момент написания статьи, т. е. 15 ноября 2022 года). По части результатов процитирую статью дословно:

Of the 357 valid packages, 54 (15 percent) contained wheels with ABI version violations. In other words: roughly one in six packages had wheels that claimed support for a particular Python version, but actually used the ABI of a newer Python version.

More severely: of those same 357 valid packages, 11 (3.1 percent) contained outright ABI violations. In other words: roughly one in thirty packages had wheels that claimed to be stable ABI compatible, but weren’t at all!

In total, 1139 (roughly 3 percent) Python extensions had version violations, and 90 (roughly 0.02 percent) had outright ABI violations. This suggests two things: that the same packages tend to have ABI violations across multiple wheels and extensions, and that multiple extensions within the same wheel tend to have ABI violations at the same time (which makes sense, since they should share the same build).

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

В статье мимолётом упоминается, что им не удалось найти кошкодевочек, в отличие от moyix.

#prog (somewhat #python) #menacingopensource #article

Someone’s Been Messing With My Subnormals!

TL;DR: After noticing an annoying warning, I went on an absurd yak shave, and discovered that because of a tiny handful of Python packages built with an appealing-sounding but dangerous compiler option, more than 2,500 Python packages—some with more than a million downloads per month—could end up causing any program that uses them to compute incorrect numerical results.

Или чуть более подробно: в силу каких-то сомнительных решений в GCC (равно как и в clang, который старательно скопировал его поведение) активация флага -Ofast подразумевает активацию флага -ffast-math, который, в свою очередь, при компиляции разделяемой библиотеки генерировал для неё конструктор, который, помимо всего прочего, выставлял в процессоре флаг, регулирующий поведение операций над плавающей точкой — более конкретно, FTZ/DAZ, при активации которого операции, которые выдали бы субнормальные числа с плавающей точкой, вместо этого выдают ноль. Несколько нативных расширений были скомпилированы с флагом -Ofast, которые в результате стали расширениями, банальный импорт которых менял поведение арифметики чисел с плавающей точкой для всего процесса, включая код из NumPy.