Интерфейс C / C ++ с использованием различных инструментов Python

Boost.Python насколько я могу судить, был разработан с двумя основными целями:

1. Предложите разработчикам на Python C ++ «pythonic» API на C ++ для разработки расширений — такой, чтобы
2. … Архитекторы этого API будут стараться изо всех сил, чтобы по-человечески изолировать свою целевую пользовательскую базу разработчиков от деталей реализации базовый Python C-API — в частности, они не хотят, чтобы пользователи манипулировали PyObject* значения и количество ссылок.

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

1. если ваш проект уже приобрел использование Boost,
2. примерно как 98% возможных сценариев использования Python-to-C ++.

Мне лично не нравится использовать Boost; если вы схожи по своему положению и способны принимать управленческие решения такого рода для вашего проекта, вы можете получить то, что, я считаю, является подавляющим большинством API Boost.Python C ++ без издержки Boost-зависимости, если вы используете pybind11 — новый проект, использующий функции C ++ 11, реализующий низкоуровневые инструменты, необходимые для псевдопифонического API.

TL; DR: pybind11 является Boost.Python для разработчиков с умеренной до тяжелой аллергии Boost. Оба эти инструмента заставляют вас написать слой C ++, который представляет ваш существующий API — который может быть функциями, типами, шаблонами и т. Д. — в виде аналогичных структур Python через один или несколько модулей Python.

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

1. Оптимизация кода Python путем разумного перемещения «горячей» идиомы из интерпретируемого домена Python в домен Cython, скомпилированный собственными силами; а также
2. Предоставление интерфейса Python для уже существующей библиотеки C или C ++.

… Хотя это разные задачи, часто пишут расширение для того, чтобы запустить что-то быстрее, чем можно в одном только Python, и поэтому использование Cython по причине № 1 может устранить необходимость в № 2 (независимо от инструментов, которые можно использовать).

Мне нравится Cython, но я нахожу, что его использование для взаимодействия (использование # 2) улучшается, когда кто-то знает C ++ довольно холодно. Очень легко выбрать Cython и использовать его для оптимизации кода Python с узкими местами (используйте # 1), не будучи опытным C-хакером или любителем C ++ — но это, IMO, не распространяется на Cythonic-интерфейс.

Это, конечно, очень субъективная оценка — приглашающему предлагается сделать несколько примеров программ с этими структурами и сделать свои собственные выводы.