"написание привязки к Python" против "с использованием командной строки напрямую"
У меня есть вопрос, касающийся привязок Python.
У меня есть командная строка, которая предоставляет некоторые функциональные возможности, и код повторно анализируется для обеспечения функциональности через общую библиотеку. Я хотел знать, какое реальное преимущество я получаю от "написания привязки Python для разделяемой библиотеки" по сравнению с "непосредственным вызовом командной строки".
Я думаю, что одним из очевидных преимуществ будет производительность: общая библиотека будет связывать один и тот же процесс, а функциональность может вызываться в одном и том же процессе. Это позволит избежать запуска нового процесса через командную строку.
Какие еще преимущества я могу получить от написания привязки Python для такого случая?
Благодарю.
1 ответ
Я с трудом представляю себе случай, когда кто-то предпочел бы обернуть интерфейс командной строки библиотеки, а не саму библиотеку. (Если нет библиотеки, которая поставляется с аккуратным интерфейсом командной строки, будучи внутренним беспорядком; но OP указывает, что те же функциональные возможности, доступные через командную строку, легко доступны с точки зрения вызовов функций библиотеки).
Самым большим преимуществом написания привязки Python является четко определенный интерфейс данных между библиотекой и Python. В идеале, библиотека может работать непосредственно с памятью, управляемой Python, без какого-либо копирования данных.
Чтобы проиллюстрировать это, давайте предположим, что библиотечная функция делает что-то более сложное, чем печать текущего времени, то есть она получает значительный объем данных в качестве входных данных, выполняет некоторую операцию и возвращает значительный объем данных в качестве выходных данных. Если входные данные ожидаются как входной файл, Python должен будет сначала сгенерировать этот файл. Он должен убедиться, что ОС закончила запись файла перед вызовом библиотеки через командную строку (я видел несколько библиотек C, где sleep(1) звонки были использованы в качестве лейкопластыря для этого вопроса...). И Python должен каким-то образом получить вывод обратно.
Если интерфейс командной строки не полагается на файлы, но получает все аргументы в командной строке и выводит выходные данные в stdoutPython, вероятно, должен преобразовывать двоичные данные в формат строки, не всегда с ожидаемыми результатами. Также нужно трубу stdout назад и разбери это. Не проблема, но получить все это правильно - большая работа.
Как насчет обработки ошибок? Ну, интерфейс командной строки, вероятно, будет обрабатывать ошибки, печатая сообщения об ошибках на stderr, Поэтому Python также должен собирать, анализировать и обрабатывать их. OTOH, соответствующая библиотечная функция почти наверняка сделает флаг успеха доступным для вызывающей программы. Это гораздо удобнее для Python.
Все это, очевидно, влияет на производительность, о которой вы уже упоминали.
В качестве еще одного момента, если вы разрабатываете библиотеку самостоятельно, через некоторое время вы, вероятно, обнаружите, что рабочий процесс Python сделал весь интерфейс командной строки устаревшим, поэтому вы можете полностью отказаться от его поддержки и сэкономить много времени.
Так что я думаю, что есть ясное обоснование для привязок Python. Для меня одна из самых сильных сторон Python - это простота создания и поддержки таких оболочек. К сожалению, существует около 7 или 8 одинаково простых способов сделать это. Для начала рекомендую ctypes, поскольку он не требует компилятора и будет работать с PyPy, Для лучшей производительности используйте нативный C-Python API, который я также нашел очень простым для изучения.