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

Проще разве что "hello, world". pyalsa это хорошо отлаженный и отформатированный код, читается как роман. Нужно просто начать с самого маленького по объёму файла, параллельно заглядывая в официальную документацию по Python/C API.

Какие функции использовать - напрямую зависит от того, что нужно. Если все типы стандартные (int, float, char* и т.д.), это одно. Если типы не стандартные - совершенно другое. Если у функций много аргументов, причём некоторые могут быть заданы по-умолчанию - это третье. В целом, лично я установил для себя всего одно правило: модуль, написанный на С, должен обеспечивать максимально "питонистый" интерфейс. К примеру, если нужно вызвать функцию С, которая принимает аргументом структуру, то в Python эта структура должна быть представлена словарём - естественным для Python типом данных. Если функция С возвращает код ошибки, нужно не возвращать в Python этот код ошибки, а генерировать исключение - потому что для Python это, опять же, наиболее естественное и ожидаемое поведение. Причём исключения должны быть по возможности стандартными. Например, некорректное значение аргумента функции => генерируем ValueError. Если подходящего класса исключений в стандартной библиотеке Python нет, то нужно создать свой класс и использовать его. И так далее, в том же духе. "Питонистость" во всём модуле.

Что касается примеров, то я и сам нигде не мог их найти. Просто брал маленькие краткие биндинги и смотрел, как они написаны. Читал документацию. В этом Сила открытого софта 

Это сообщение отредактировал(а) rsm - 24.5.2012, 17:08

Я больше сталкивался с тем, что делается копия сишного апи на питоне(_winreg/pycurl), а для него уже пишутся обертки.

Увы, не всегда возможно. Например, когда C оперирует сложными структурами - тут без вариантов, нужно сразу писать конвертацию "структура" <=> "словарь". Другой вариант - когда C реализует квази-ООП. Ещё вариант - асинхронная обработка данных. В общем, каждый случай индивидуален. Но в целом да, согласен - на некоторых задачах быстрее и проще сначала написать интерфейс модуля "в стиле С", а потом уже добавить ему "питонистость" средствами самого Python.

Только добавлять эту "питонистость" - работа, видимо, неблагодарная, поэтому о ней часто забывают.

"Питонистость" (а точнее, ООП-шность - "жавоидность" будет выглядеть почти так же) состоит не из структур данных, а, например, вместо кодов возврата должны бросаться исключения. И этому не всегда следуют даже встроенные модули питона (poplib/imaplib возвращают кортежи с содержимым, которое хрен запомнишь). Еще программа не должна грохаться с сегфолтом, а бросать вменяемое исключение, поэтому, например, кто-то должен проверять типы параметров - или нативный модуль, или питоновая обертка (wireshark через lua api грохался на ура, если ему подсунуть не тот обьект).


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

Ключевые моменты "питонистости" оберток - это:

• ООП интерфейс со всеми прибамбасами (инкапсуляция, возврат обьекта, а не числового идентификатора, который потом куда-то хреначится)
• Исключения вместо кодов возврата
• keyword arguments
• Собственно питонистость - например, в pycurl прокси устанавливается тремя опциями отдельно (хост, порт, тип), пистонисто это должен быть кортеж (хост, порт, тип) как один параметр.
• Мне лично больше всего не нравится, когда обертки "текут", т.е. для того, чтобы ей нормально пользоваться, надо знать C и сишный интерфейс, который вроде бы должен полностью закрываться высокоуровневым API. То документацию не напишут, потому что "нинужно" (касается как раз апинсорса), то обертка "течет", надо следить самому за типом параметров - а для начала, если программа упадет, догадаться, что же ты сделал не так.

Это сообщение отредактировал(а) Karadul - 26.5.2012, 17:14

Не все программеры - быдло-кодеры 


В определении того, метод какого класса нужно вызвать.


Конечно, только нужно не забыть про сборку мусора и GIL.

Тем не менее, _winreg попал в стандартную библиотеку питона. Хотя нормальная обертка для него - строк на 20.


А что со ними?

Сишкопроблемы  Языки со сборкой мусора от них свободны.

В асинхронных модулях нужно быть предельно внимательным к контролю времени жизни объектов, т.к. по факту никакого достаточно прямого способа обнаружить утечки памяти нет. Добавим к этому GIL - и получаем феерическую головную боль. Поэтому простой обёрткой уже не обойтись - нужно создавать объекты и манипулировать ими со стороны С. В противном случае поведение становится трудно предсказуемым.

А чем плох именно GIL?
Можно сделать так, что обьектом займется питоновский мусоровоз?

Проблема не в GIL как таковом, проблема в скрещивании С и Python. Требуется уделить большое внимание тому, чтобы объект, убранный GC в Python, не был повторно освобождён из С. Или наоборот - чтобы Python не пытался использовать объект, уже освобождённый в С. Из-за наличия в интерпретаторе мощных оптимизаций расхода памяти, по адресу, который уже освободили, сразу же могут оказаться совершенно другие данные, которые Python и/или С могут воспринять как должное. Такие ошибки сложнее всего отловить. Или, к примеру, гонка за ресурсы - что получится, если Python уже заблокировал GIL, а часть со стороны С изменила какой-то объект? Конечно, средства для устранения подобных ситуаций предусмотрены, но за ними нужно пристально следить. Да и то нет полной гарантии отсутствия ошибок.

Ыыыы, а это когда из си вызывается питон или модули на питоне написаны на си?

Не принципиально. Как правило, на С пишется модуль и подключается к Python. Можно и наоборот, но такое действительно нужно крайне редко.

Плагины на питоне? Для lua это вообще основной use case.

Да, бывает. Но действительно - крайне редко.

А зря. Лепят всюду этот луа, в котором ни стандартной библиотеки искаропки, ни даже нормального ООП.