Sanya28
Можете ответить: что вас привлекло в вашем решении?
Я бы не сказал привлекло. Скорее наименьшее из зол (ctypes, cffi, swig, cython, sip, common c extension).
Последнее время были заботы с приделыванием интерфейсов к миллионам статических объектов.
ctypes, cffi просто умирают на этой задаче. а pybind11 держит удар.
Sanya28
но честно говоря не нашел преимуществ над Cython
Давненько смотрел Cython, не являюсь по нему специалистом, могу чтото и упустить.
Основные проблемы которые не дали использовать Cython именно для интерфейсов с C++
1 интерфейсы на c++ в pybind11 надо описать файл с интерфейсами в c++ один раз.
А в Cython явно не один раз.
http://docs.cython.org/en/latest/src/userguide/wrapping_CPlusPlus.htmlТе описываем сишный объект
cdef extern from "Rectangle.h" namespace "shapes":
cdef cppclass Rectangle:
Потом питоновский:
cdef class PyRectangle:
cdef Rectangle c_rect # Hold a C++ instance which we're wrapping
def __cinit__(self, int x0, int y0, int x1, int y1):
self.c_rect = Rectangle(x0, y0, x1, y1)
Всякие ссыки на внутренние объекты self.c_rect выглядят не только многословно но и глупо.
2. Билд при помощи o python setup.py build_ext –inplace в больших проектах просто неприемлем. Проект имеет кучу зависимостей, надо одновременно использовать разные компиляторы, управлять разрядностью образа, способом отладки используемым рантаймом и т.д , и т.п. Инструментарий сборки лучше делать один раз и он зачастую непростой и делается он на условно сишной стороне.
3. Я в документации ситона не нашел способа работы с указателями, а это совершенно необходимо для нас, да думаю и для вас.
Sanya28
За кадром остался вопрос отладки и профилирования С++ кода
Тут я собственно не понимаю в чем у вас проблема. Питон вместе с подгруженными модулями это обычное приложение на C++. Берете и пользуетесь обычными отладчиком и профилировщиком. Ничем не отличается от сишного приложения. Ну при желании правда можно и питоновский отладчик/ide запустить из под отладчика сишного. Тогда будет два уровня отладки, питоновский и сишный.
Sanya28
асколько я понял в вашем случае также необходимо как- то передавать вычислительному ядру исходные данные,
Для работы с объектами вы их создаете. В конструктор объектов передаются аргументы, очевидно на питоновской стороне. Почему это лишний код? Он всегда необходим. А конвертацией чисто питоновских структур данных в сишные занимается по большей части рекурсивный код автоматических преобразований типов (в pybind11). Оно все по умолчанию делается, вы об этом можете не заботиться пока вас производительность этого процесса устраивает.
Sanya28
Интересно, есть ли способ преобразовать Python- программу в корректный проект с исходниками на С++
А зачем вам тогда вообще питон нужен? Пишите сразу на C++. Про отладку я писал, проблем нет.
Да и забыл упомянуть самый часто используемый у нас способ связывания питона и C++.
Сиашное приложение работает само питоновское само, а общаются они через сокеты по заранее согласованному протоколу. На питоне есть библиотека которая создает прокси объекты привязанные к объектам на сишной сотороне. Простненький такой RPC.
По сути ошибки в приложении не валят питон, питон не валит приложение, нет проблем объединить несколько приложений, причем даже работающих на разных машинах.