python extension module: как правильно преобразовать стуктуру Си в класс Python'а ?

Конечно, можно без swig. Только, возможно, придется познакомиться с особенностями работы потоничьего GC, который, внезапно, основан на подсчете ссылок. Нет, это не каламбур. Это констатация факта. По своему это даже удобно для написания расширений к питону на системных языках типа С и Rust (через обертку на C). Настоящий GC, но с подсчетом ссылок.

Если вам не нужен GC, то написание расширения не так уж и сложно. Документация та самая.

Но чисто для общего развития, а можно ли вручную создать такой extension без использования swig?

Это самый верный путь. Главное помнить, что это С, и что важно не налажать со счетчиками ссылок в питоновских объектах.

но пока я в упор не вижу там похожих примеров, всё на уровне helloworld

https://docs.python.org/3/extending/newtypes_tutorial.html

Если с С будет слишком сложно, то можно взять boost python и выписать API на нем.

http://a-iv.ru/pyart/cpp2py.pdf

функции получения информации хотят на входе указатель на структуру. Т.е. выделить память нужного размера требуется до вызова

Не распарсил, можно пример?

Насчёт лонга гляну, сам как то обычно интами обходился

Не распарсил, можно пример?

struct mys {
   int a;
   int b;
}

struct mys * beep = malloc(sizeof(struct mys));

megafunc(beep);

printf("beep.a = %d, beep.b = %d\n", beep->a, beep->b);

free(beep);

После биндинга через SWIG:

from mymodule import *
beep = mys()
megafunc(beep)
print beep.a, beep.b

У меня под SWIG 3.08 типы полей структуры size_t и unsigned long long работают из коробки (кастуются к питоновскому long).

Но чисто для общего развития, а можно ли вручную создать такой extension без использования swig?

Можно, но это гемор. Хотя кроме SWIG есть еще какие то системы биндинга, я их не помню. SWIG хорош когда нужно малой кровью забиндить много сишного кода, или когда сишный код меняется а че то в прокладке адаптировать руками лень. Если кода мало и есть много каких то экзотических ситуаций - да, возможно вместо SWIG лучше взять что то другое. Но я пока не уверен что это Ваш случай…

Т.е. чтобы на стороне питона операции шли исключительно с объектами? Когда память под структуру инициализируется в конструкторе питоньего объекта, а фукнции можно передать объект, и она корректно возьмёт из его внутренностей структуру?

Есть две крайности - можно как Вы написали собрать в питоне объект (питоний) и отдать его сишной функции, которая через PyAPI его разберет. Это потребует много букв, PyAPI очень многословен, кроме того может потечь память (как Serral и dave выше писали).

Можно на стороне питона через struct упаковать данные в строку отвечающую сишной структуре (если знаете как она устроена) и отдать сишной функции которая просто возьмет содержимое строки и кастанет указатель на него к нужному типу. Букв меньше, но нужно знать как все уложено в структуре.

Нафиг он вообще сдался, этот SWIG?

есть ещё pybind11. Насколько я понимаю, «подружить» его с C особого труда не составит

можно ли вручную создать такой extension без использования swig?

Конечно можно. Я вообще не знаю swig, но extension для python делать могу, там легко всё, используй cython.

dave, Serral, AntonI, Sahas, fsb4000

спасибо, буду пробовать

да, на утечки памяти мне придётся обращать внимание, т.к. пишу агент мониторинга, который будет работать постоянно

перенести структуру на уровень питона видимо не выход, т.к. мне придётся вручную поддерживать разные версии структур для разных версий ОС

параллельно буду читать документацию к swig, вдруг удастся объяснить ему ,что именно мне нужно поменять при автоматической генерации

У меня под SWIG 3.08 типы полей структуры size_t и unsigned long long работают из коробки (кастуются к питоновскому long).

Странно. возможно дело в оси ( aix ) или endianes. пробовал swig 3.0.11 и вручную собранный последний 4.0.1, без разницы. python 3.7.0

попробую пересобрать через gcc вместо ibm xlc, вдруг что изменится

потому, что жизнь слишком коротка

root@lp-aix-ok-256:/home/ok/perfstat# du -smx perfstat_wrap.c
3.59    perfstat_wrap.c

Э… От оси это вроде не должно зависеть, это чисто проблемы внутрисвигового парсинга. Вот всякие uintXX_t он сходу не ест.

Если Вы выложите (или кинете мне как то) структуру которую биндите я у себя попробую.

ЗЫ ещё финт ушами - свиг можно запускать на другой машине под другой осью, а уже его выхлоп копировать куда надо и там собирать. Правда надо убедиться что при запуске свига всякие дефайны правильно стоят (как на целевой машине). В общем это кросс-свигизация, я так делаю когда на целевой машине свига вообще нет.

Ну гляньте пдф которую я выше выкладывал, она в смысле обзора возможностей того как заставить свиг работать в чем то лучше чем доки (короче), хотя и десятилетней давности.

Блиин, я идиот. Был невнимателен, в хедере библиотеки так и написано «u_longlong_t»

Огромное спасибо за pdf, сразу нашлось решение - просто добавить typedef в конфиг для swig

typedef unsigned long long u_longlong_t;

u_longlong_t

Ух какие затейники эти разработчики:-)

Для враппинга стандартных вещей (которые не работают из коробки) в свиг в .и-файл нужно подключать всякие string.i, stdint.i и пр.

Ну и есть очень мощный механизм typemap-ов, я к сожалению в нем слабо разбираюсь.

А вот в память сишного объекта напрямую из питона лажу и свиговую систему типов хакал. Если что то не заводится с типами можно для начала глазами глянуть TYPES TABLE во _wrap.cxx

В общем если что зовите:-) Удачи!

Скажите пожалуйста, это случайно была не та тема, где можно сделать вставку кода на Си в Python?