Comments 12
То есть фактически ни о каком «встраивании кода» (как можно предположить из заголовка) речи и не идёт…
А что тогда понимается под фактическим встраиванием? Чем этот подход по своей сути отличается от того, что предлагает стандартный механизм или Boost::Python? Питоновский код всё так же исполняется в интерпретаторе, просто вместо вот этого:
Используя API CPython, вы должны были бы запустить интерпретатор и выполнить множество преобразований параметров и возвращаемого значения.
используется обёртка в виде динамической библиотеки, в которой всё это под капотом.

Думаю, отлаживать такой питоновский код становится не очень удобно из-за всей этой обвязки с импортом модуля расширения. В доке даже есть раздел об этом.

Хотя идея мне, вообще, нравится. Всё это, например, можно было бы использовать в приложении с плагинами.
>используется обёртка в виде динамической библиотеки, в которой всё это под капотом.

Вот и я об этом. Просто линковка библиотек на другом языке и интерфейс для их использования. А встраивание кода — это использование кода в оригинальном исходнике, например, как в C::Blocks (Perl).

Если очень нужно, то допилить встраивание именно до такого варианта с помощью C’шного препроцессора и простого скрипта на том же Python, который будет вырезать код на Python во временный файл и запускать создание библиотеки, несложно. А вот сделать код, который создаёт такие библиотеки сложнее.


Хотя пока такой скрипт не приведён название всё же стоит изменить на «создание разделяемых библиотек на Python».

У оригинальной статьи в названии все же «Встраивание...», хотя вы правы, в статье речь на самом деле идет только о создании библиотек.
Не нужно. И так просто, «с помощью препроцессора и простого скрипта» ничего не получится. Потому что суть встраивания не в выдирании модулей из общего кода, а в совместной компиляции, при которой гостевой код имеет полный доступ ко всей инфраструктуре «хост»-кода без дополнительных усилий. Ещё наглядный пример — inline assembler в C/C++, причём больше MASM/Intel-вариант, чем GNU.

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

Есть примеры, где это может понадобиться? Обычно нужно обратное — пишется ядро на C или C++ и используется в Python-приложении.

На вскидку, скриптование в игре. Да и вообще везде, где надо программировать логику без перекомпиляции.

Мы использовали Python-плагины в некотором околонаучном софте, который был написан на C++. Система плагинов была разработана так, чтобы можно было писать плагины и на C++ и на Python. Это очень удобно для проверки и обкатки каких-то новых алгоритмов/концепций/методов, связанных с предметной областью. Сначала пишется прототип на Python, подключается в виде плагина, алгоритм отлаживается, дорабатывается. Когда всё готово, делается реализация на C++, и плагин на Python заменяется плагином на C++ с тем же интерфейсом.
Какие ограничения по использованию питоновских модулей с помощью такого импорта?
Прошу уточнить вопросы технического плана:
1) gcc вместо Clang отаботает также, с теми же параметрами? Ни разу с Clang работать не приходилось.
2) Указано что *.dylib — динамическая библиотека, но в примере указан вариант с включением файла в конечный исполняемый файл. Поправьте, если это не так. Вопрос — это на самом деле динамическая библиотека, то что в Linux часто имеет шаблон libNamelibrary.so?
Точно ответить, к сожалению, сейчас не могу.

С gcc должно работать также. Во всяком случае, для такого простого примера.
По второму вопросу — видимо да, на Linux будет генерироваться библиотека с расширением .so
*.dylib — расширение для динамических библиотек используемое в OS X
Only those users with full accounts are able to leave comments. Log in, please.