[С-to-Python]конвертация кода

Если бы у меня возникло такое желание, я бы обернул Си-библиотеку в Python через ctypes :)

логично, но выглядеть будет сурово))

man sip, swig

sip - как раз то что доктор прописал в данном случае, имхо

> man sip, swig

не заню, как насчет SIP, но SWIG - это неумолимый песец. Лучше уж python-ctypeslib.

ну swig я не особо юзал на практике, но имхо там не так всё страшно

а, sip, очень даже незамысловатый и относительно простой, пруф

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

> sip, очень даже незамысловатый и относительно простой,

Не использует ctypes, полного Си/Си++-парсера не имеет. Не, я определенно предпочитаю python-ctypeslib :)

> sip, очень даже незамысловатый и относительно простой,

Не использует ctypes, полного Си/Си++-парсера не имеет. Не, я определенно предпочитаю python-ctypeslib :)

1) и что?

2) и пофиг, а руками меньше ковыряться, а проекты на нём достаточно сложные выполняются нормально (проверено электрониками :))

> 1) и что?

ctypes - это как бы стандарт. Я его знаю и умею им пользоваться. Учить что-то другое большого желания нет.

2) и пофиг, а руками меньше ковыряться

Меньше по сравнению со SWIG? Это не показатель.

> 2) и пофиг, а руками меньше ковыряться

Меньше по сравнению со SWIG? Это не показатель.

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

и да, есть мнение что для всех внешних функций (foreign functions) так или иначе используют ctypes, просто SIP генерит байндинги автоматом на основе размеченного хедера, что на мой взгляд удобнее чем возиться руками, опять же можно посадить молодого негра и не бояться особо

???

PROFIT!!!

PS и да, SIP использовался для создания PyQt, что говорит о его достаточной проработанности, имхо

1) и что?

ctypes - это как бы стандарт.

SIP'ом завёрнут весь Qt

Я его знаю и умею им пользоваться.

очень рад за Вас :)

Учить что-то другое большого желания нет.

даже если это позволит Вам поднять производительность?

>>> 2) и пофиг, а руками меньше ковыряться

Меньше по сравнению со SWIG? Это не показатель.

ну и зачем играть в шланг?

Э то не я не играю в шланг, а ты выражаешься сумбурно.

меньше работы по сравнению с тем что Вы будете делать при помощи ctypes

Какой еще ручной работы? Я не собираюсь писать ctypes-определения руками. Если что, python-ctypeslib - это название пакета, который автоматически генерит байндинги из xml-описаний, которые, в свою очередь, генерятся gccxml.

что на мой взгляд удобнее чем возиться руками

Уже давно не обязательно делать ctypes «руками».

> ну и зачем играть в шланг?

Э то не я не играю в шланг, а ты выражаешься сумбурно.

а, ну сорри тогда, я тут параллельно эксперименты ставлю да и поздно уже, видимо заносит :)

> что на мой взгляд удобнее чем возиться руками

Уже давно не обязательно делать ctypes «руками».

хме, ну значит я отстал от жизни :) надо будет «освежить» знания по теме

и да, пожалуй вот хорошее, взвешенное мнение

Based on my little survey above, I would suggest using SWIG to write wrappers for relatively small libraries, while SIP probably provides a more manageable infrastructure for wrapping large libraries (which I know I did not demonstrate!)

Pyrex is astonishingly easy to use, and it may be a good option if you have a small library to wrap. My guess is that you would spend a lot of time converting types back and forth from C/C++ to Python, but I could be wrong.

ctypes is excellent if you have a bunch of functions to run and you don't care about extracting complex data types from them: you just want to pass around the encapsulated data types between the functions in order to accomplish a goal.

взято отюда

Если бы у меня возникло такое желание, я бы обернул Си-библиотеку в Python через ctypes :)

А я бы, а я бы использовал Cython и не парился бы вообще!)

Например есть взаимосвязанные сишные функции и структура - без особых проблем делаем питоновский класс которое это все красиво связывает и использует

cdef extern from "libev.h":

    void *ev_default_loop(unsigned int flags)
    void ev_loop(void* loop, int flags)

    struct timer_ev "ev_timer":
        int active
        int pending
        int priority
        void *data
        void *cb
        double at
        double repeat

    void ev_timer_start(void* loop, timer_ev *ev)
    void ev_timer_stop(void* loop, timer_ev *ev)


cdef void timer_cb(void *loop, timer_ev *ev, int revents) with gil:
    cdef EvTimer watcher = <EvTimer>ev.data
    watcher.callback(watcher, revents, watcher.argv)


cdef class EvTimer:
    cdef timer_ev ev
    cdef object callback, argv

    def __init__(self, callback, second, argv=None):
        cdef void* c_self = <void*>self
        self.callback = callback
        self.argv = argv
        self.ev.active = 0
        self.ev.pending = 0
        self.ev.priority = 0
        self.ev.data = c_self
        self.ev.cb = <void*>timer_cb
        self.ev.at = second
        self.ev.repeat = second


    def start(self):
        if(self.ev.active == 0):
            ev_timer_start(ev_default_loop(0), &self.ev)

    def stop(self):
        if(self.ev.active != 0):
            ev_timer_stop(ev_default_loop(0), &self.ev)

> и да, пожалуй вот хорошее, взвешенное мнение

Этому мнению 3 года, python-ctypeslib не рассматривается, говорится о ручном написании ctypes-кода. Вывод - нерелевантно.

и да, пожалуй вот хорошее, взвешенное мнение

Этому мнению 3 года, python-ctypeslib не рассматривается, говорится о ручном написании ctypes-кода. Вывод - нерелевантно.

так приведите релевантное, кто ж Вам мешает? :)

>> Вывод - нерелевантно.

так приведите релевантное, кто ж Вам мешает? :)

Я не искал мнение в сети :) У меня есть свое основанное на опыте работы со SWIG, самодельным генератором на DWARF и python-ctypeslib.

Правда, по-быстрому ничего релевантного найти не удалось, хотя вот это: http://blog.vrplumber.com/index.php?/archives/1120-Why-ctypes-for-OpenGL-Sinc... более-менее совпадает с моим опытом использования SWIG :)

Правда, по-быстрому ничего релевантного найти не удалось, хотя вот это: http://blog.vrplumber.com/index.php?/archives/1120-Why-ctypes-for-OpenGL-Sinc... более-менее совпадает с моим опытом использования SWIG :)

мнение

Wednesday, August 17. 2005

этому мнению 5 лет, ещё менее релевантное, как Вы говорите

> этому мнению 5 лет, ещё менее релевантное, как Вы говорите

Древность этого мнения только повышает его релевантность, потому что показывает, что даже инструменты 5-летней давности вполне справлялись с автоматической генерацией ctypes-кода (pyOpenGL - на ctypes, куча кода сгенерирована автоматически).

Древность этого мнения только повышает его релевантность,

Вы точно уверены в том что вполне ясно понимаете смысл термина «релевантность»?

> Вы точно уверены в том что вполне ясно понимаете смысл термина «релевантность»?

Да.

Раскурил ман по SIP. Он немного не в ту сторону работает. Как я понял, на выходе всегда будет С-шный код, а мне надо Python.

Раскурил ман по SIP. Он немного не в ту сторону работает. Как я понял, на выходе всегда будет С-шный код, а мне надо Python.

там на выходе получается питоновский модуль, который в питон импортите и работаете, вроде оно, или не?

Вы точно уверены в том что вполне ясно понимаете смысл термина «релевантность»?

Да.

ну, пусть будет по-вашему

> Раскурил ман по SIP. Он немного не в ту сторону работает

Трансляторов с Си в Питон я лично не знаю. Сомневаюсь, что они существуют в природе.

>Трансляторов с Си в Питон я лично не знаю. Сомневаюсь, что они существуют в природе.

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

> Я пытаюсь найти решение которое упростит задачу, что бы не переписывать метры исходного кода на Python. При этом, реализовав нормальную кроссплатформенную библиотеку

Тебе уже про Цитон намекнули вроде. Хотя да, если ни Питон ни Си нормально не волокешь заюзай все таки какой-нибудь генератор )

> что бы не переписывать метры исходного кода на Python. При этом, реализовав нормальную кроссплатформенную библиотеку.

Ну вообще-то Си тоже может быть кроссплатформенным. И если у тебя метры исходного кода, то переписывание их на другой язых - идея изначально провальная. В лучшем случае можно попробовать вычистить системно-зависимый код.

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

внезапно, 3/4 пистона написано на Си и вполне все кросс