#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.

#prog #python и, видимо, #suckassstory?

#prog #python #article #abnormalprogramming

Python's Preprocessor

Python позволяет иметь в первой строке комментарий, который говорит о том, какая кодировка используется для текста файла. Имя кодировщика ищется в специальном месте, и механизм для предоставления этого кодировщика позволяет исполнять произвольный код на Python. Как следствие, это позволяет интерпретировать дальнейший текст как угодно — с синтаксисом, произвольно далёким от Python.

(thanks @itpgchannel)

#prog #python #article

Проблемы вызова Python кода из C кода

Или про то, как немного странный (но легальный) код на Python может привести к сегфолту интепретатора.

#prog #python #article

И ещё серия старых (2012 год) статей от разработчика PyPy о том, как можно написать код таким образом, чтобы получить наибольшее преимущество от трассирующего JIT:

Controlling the Tracing of an Interpreter With Hints, Part 1: Controlling the Extent of Tracing

Controlling the Tracing of an Interpreter With Hints, Part 2: Controlling Optimization

Controlling the Tracing of an Interpreter With Hints, Part 3: Putting it All Together — про то, как организовать структуру представления объектов так, чтобы получить выгоду от JIT (ибо наивный подход со словарями методов толком не ускорить)

#prog #python

IceCream — Never use print() to debug again

Или dbg! из Rust в Python.

TL;DR:

from icecream import ic

def foo(i):
    return i + 333

ic(foo(123))

Вывод:

ic| foo(123): 456

ic возвращает аргументы:


>>> a = 6
>>> def half(i):
>>>     return i / 2
>>> b = half(ic(a))
ic| a: 6
>>> ic(b)
ic| b: 3

#prog #cpp #python

Что общего у C++ и Python?

Правильно: что в C++, что в Python нельзя распаковывать кортежи в аргументах лямбды.

#prog #python

Причём в Python 2.x можно было писать код вида

lambda (x, y): (y, x)

, а в Python 3 это убрали после PEP 3113, причём по причинам, которые, на мой взгляд, можно было бы и исправить.

#prog #csharp #c #python #meme

#prog #python #suckassstory

#prog #python #article

Новый лучший способ форматирования строк в Python

t-строки — новый вид строк в Python. Походит на format_args! в Rust в том смысле, что позволяет захватывать переменные по имени и создаёт просто шаблон со значениями переменных вместо уже форматированной строки. Как следствие, это позволяет одновременно ускорить форматирование и отделить собственно образование шаблона от его интерпретации. В статье приводится пример форматировщика SQL-запросов: он может при форматировании автоматически экранировать значения. Аналогично для шаблонизатора HTML.