Оборачивание библиотеки C в Python: C, Cython или ctypes?

Предупреждение: впереди мнение разработчиков Cython.

Я почти всегда рекомендую Cython над ctypes. Причина в том, что он имеет гораздо более плавный путь обновления. Если вы используете ctypes, многие вещи будут простыми вначале, и, конечно же, здорово написать свой код FFI на простом Python, без компиляции, создания зависимостей и всего этого. Однако в какой-то момент вы почти наверняка обнаружите, что вам нужно много раз звонить в вашу библиотеку C, либо в цикле, либо в более длинной серии взаимозависимых вызовов, и вы хотели бы ускорить это. То, что вы заметите, что вы не можете сделать это с помощью ctypes. Или, когда вам нужны функции обратного вызова, и вы обнаружите, что ваш код обратного вызова Python становится узким местом, вы хотите ускорить его и/или переместить его на C. Опять же, вы не можете сделать это с помощью ctypes. Таким образом, вы должны переключать языки в этот момент и начинать переписывать части своего кода, что потенциально может превратить ваш код Python/ctypes в обычный C, таким образом испортив все преимущества написания вашего кода на простом Python в первую очередь.

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

Итак, ctypes приятно делать простые вещи и быстро запускать что-то. Однако, как только все начнет расти, вы, скорее всего, дойдете до того, что заметите, что лучше использовать Cython с самого начала.

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

Cython - это надмножество языка Python. Вы можете выбросить на него любой действительный файл Python, и он выплюнет действительную программу на C. В этом случае Cython будет просто отображать вызовы Python в базовый API CPython. Это приводит к ускорению на 50%, потому что ваш код больше не интерпретируется.

Чтобы получить некоторые оптимизации, вы должны начать рассказывать Cython дополнительные факты о вашем коде, такие как объявления типов. Если вы это достаточно догадаетесь, он может сварить код до чистого C. То есть цикл for в Python становится циклом for в C. Здесь вы увидите значительное увеличение скорости. Вы также можете ссылаться на внешние программы C.

Использование кода Cython также невероятно просто. Я подумал, что руководство затрудняет его работу. Вы буквально делаете:

$ cython mymodule.pyx
$ gcc [some arguments here] mymodule.c -o mymodule.so

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

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

Для вызова библиотеки C из приложения Python существует также cffi, что является новой альтернативой для ctypes. Это придает новый вид FFI:

• он обрабатывает проблему увлекательным, чистым способом (в отличие от ctypes)
• не требуется писать код не Python (как в SWIG, Cython,...)

Я выброшу еще один: SWIG

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

Если вы используете SWIG, вы создаете новый модуль расширения python, но при этом SWIG делает большую часть тяжелой работы для вас.

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

ctypes отлично работает, когда у вас уже есть скомпилированная библиотека blob для работы (например, библиотеки ОС). Однако накладные накладные расходы серьезны, поэтому, если вы будете делать много вызовов в библиотеке, и вы все равно будете писать код C (или, по крайней мере, скомпилировать его), я бы сказал, cython. Это не намного больше работает, и будет намного быстрее и более pythonic использовать полученный файл pyd.

Я лично предпочитаю использовать cython для быстрого ускорения кода python (циклы и целые сравнения - это две области, где особенно сияет цитон), и когда есть еще более вовлеченный код/​​упаковка других библиотек, я перейду к Boost.Python. Boost.Python можно настроить, но после того, как вы его заработаете, он упрощает код C/С++.

cython также отлично подходит для упаковки numpy (который я узнал из Отчеты SciPy 2009), но я не использовал numpy, поэтому не могу комментировать это.

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

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

Другой подход для простых программ непосредственно выполняет другой процесс (скомпилированный извне), выводя результат в стандартный вывод и вызывающий его с модулем подпроцесса. Иногда это самый простой подход.

Например, если вы создаете консольную программу C, которая работает более или менее таким образом

$miCcode 10
Result: 12345678

Вы можете вызвать его из Python

>>> import subprocess
>>> p = subprocess.Popen(['miCcode', '10'], shell=True, stdout=subprocess.PIPE)
>>> std_out, std_err = p.communicate()
>>> print std_out
Result: 12345678

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

Есть одна проблема, которая заставила меня использовать ctypes, а не cython, и который не упоминается в других ответах.

Используя ctypes, результат не зависит от используемого вами компилятора. Вы можете написать библиотеку, используя более или менее любой язык, который может быть скомпилирован в родную общую библиотеку. Не имеет большого значения, какая система, какой язык и какой компилятор. Cython, однако, ограничен инфраструктурой. Например, если вы хотите использовать Intel-компилятор на окнах, гораздо сложнее сделать работу cython: вы должны "объяснить" компилятор на cython, перекомпилировать что-то с этим точным компилятором и т.д., Что значительно ограничивает переносимость.

Если вы настроили таргетинг на Windows и решили обернуть некоторые собственные библиотеки С++, вы можете вскоре обнаружить, что разные версии msvcrt***.dll (Visual С++ Runtime) несколько несовместимы.

Это означает, что вы не сможете использовать Cython, так как итоговый wrapper.pyd связан с msvcr90.dll (Python 2.7) или msvcr100.dll (Python 3.x). Если библиотека, которую вы обертываете, связана с другой версией среды выполнения, вам не повезло.

Затем, чтобы сделать все, вам нужно создать C-оболочки для библиотек С++, связать эту оболочку dll с той же версией msvcrt***.dll, что и ваша библиотека С++. А затем используйте ctypes, чтобы динамически загружать динамическую оболочку обертки вручную во время выполнения.

Итак, есть много мелких деталей, которые подробно описаны в следующей статье:

"Красивые родные библиотеки (в Python)": http://lucumr.pocoo.org/2013/8/18/beautiful-native-libraries/

Существует также одна возможность использовать GObject Introspection для библиотек, которые используют GLib.