Comments 38
В C# очень легко подключить питон (IronPython).
В C# и подключать то не надо.
У него есть динамическая компиляция, и что важнее, менее замороченный синтаксис. +Серверный программист делился, что C# «на лету» выполняет свой код быстрее подключаемых lua,php,python…
Для С++ смысл это уже имеет…
У него есть динамическая компиляция, и что важнее, менее замороченный синтаксис. +Серверный программист делился, что C# «на лету» выполняет свой код быстрее подключаемых lua,php,python…
Для С++ смысл это уже имеет…
В C# и подключать то не надо. У него есть динамическая компиляция, и что важнее, менее замороченный синтаксис.
Синтаксис или грамматика? А то, с одной стороны, кому важен чистый синтаксис языка? а с другой, называть грамматику C# «менее замороченной» по сравнению с грамматикой Python-а — это, кхм…
я встроил Python в гейм-бота написанного на delphi (stealth.od.ua) =)
правда он бывает крешится :\ не хватает квалификации пофиксить все проблемы
правда он бывает крешится :\ не хватает квалификации пофиксить все проблемы
Хотел бы при случае повторить подобный подвиг. Исходниками делишься?
Про наличие SVN тут вычитал, но вот адреса репозитория там почему-то не опубликовано. Было б хорошо его на ReadOnly открыть для публики. С ридмишкой на счёт того, куда слать патчи в случае чего…
Вы использовали code.google.com/p/python4delphi/?
Я пробовал встраивать JavaScript в свой сервер с использованием движка SpiderMonkey (который в Firefox используется), тоже неплохо получилось. Теперь, благодаря вашей статье, захотел встроить Python. Судя по всему, Python встроить даже легче.
Не хотелось говорить, но основной язык программирования в Google С++
Прошу прощения, накатило что то ;) сам использую Python очень много и спасибо за статью.
Сильно громкое заявление.
Разные команды Гугла имеют свои предпочтения и организацию труда, в т. ч. и инструменты. С++ — да, там, где нужна производительность. Но не менее популярны там Java (например, frontend G+ на их сервлет сервере собственном работает) и Python. Есть и другие, но менее используемые (например, Sketchup имеет Ruby API для создания плагинов).
К чему я это. Там люди поступают правильно — стараются брать инструмент под задачу, а не пис++ками меряться и выбирать основной язык)) Поэтому называть С++ основным языком Гугла — не сильно корректно.
Разные команды Гугла имеют свои предпочтения и организацию труда, в т. ч. и инструменты. С++ — да, там, где нужна производительность. Но не менее популярны там Java (например, frontend G+ на их сервлет сервере собственном работает) и Python. Есть и другие, но менее используемые (например, Sketchup имеет Ruby API для создания плагинов).
К чему я это. Там люди поступают правильно — стараются брать инструмент под задачу, а не пис++ками меряться и выбирать основной язык)) Поэтому называть С++ основным языком Гугла — не сильно корректно.
Я правильно понимаю, что питон можно интегрировать во все мыслимые языки программирования?
Ну конечно не во все, но во многие популярные можно.
> При разработке прикладных программ иногда возникает необходимость предоставить пользователю какую-то достаточно гибкую, но простую систему для управления программой…
… Для таких случаев идеально подойдёт Tcl. А когда нужно что-то совсем миниатюрное — Jim.
… Для таких случаев идеально подойдёт Tcl. А когда нужно что-то совсем миниатюрное — Jim.
Lua же. Он как раз для встраивания и разрабатывался.
Тикль в данном случае работает наоборот: выгоднее к нему подключать модули на C/C++, чем его встраивать в программу на C/C++. Как уже выше заметили, идеальный встраиваемый язык — это Lua.
То же самое с Python. Embedding (то есть встраивание) порождает очень неприятную болезнь под названием «геморрой», намного более просто и удобно делать extending (пописывая себе подключаемый функционал на С).
Как уже отметили выше, Lua ужасен для встраивания и слишком сложен в качестве простой системы управления программой. Разрабатывался как встраиваемый язык, а оказался в одной нише с Python.
Вы видимо никогда не пробовали ни встроить, ни использовать. Lua не прост, он элементарен, там спецификации занимают 60кб из которых 70% — просто перечисление доступных функций. Язык в любом случае намного легковеснее и проще, чем Python. А встраивание ничего сложного не представляет: чистый C-api, очень лёгкий и удобный. В одной нише с Python он никогда не был и не будет: мощь Python опирается на титаническую стандартную библиотеку (настолько титаническую, что поговаривают об её обрезании), которой в Lua нет в принципе. Говорю, как работавший с обоими языками.
Не осилил найти ссылку. Подскажите сайт Джима?
Помнится, горели мы как-то в танке использовал хэнд-мейд фреймворк, который вызывал Py из Delphi, для SQL запросов преимуществ., а еще там был XML где-ж его нет, для создания окошек на лету. Не оправдал полет мысли тим-лида, вложенных средств…
SWIG не пробовали? Как бы уже готовые обертки, не надо городить такой большой огород для столь элементарной функциональности.
Вообще-то, SWIG (как и SIP) не для встраивания Python в программы на C\C++, а наоборот: для использования кода C\C++ в проектах на Python.
Вообще да. Но скрипты то и применяются для управления С++ кодом. Игровая логика, например. Запускаешь питоновский update, и он уже дергает нужные С++ ф-ии и обновляет состояние нужных объектов. Если взять пример построения графиков из статьи, то по идее в С++ будет ф-ия рисования точек plot(х, у), которая экспортируется в питон. А в питоне уже реализуются мат ф-ии, которые в итоге дергают plot() для построения графика этой мат ф-ии.
Есть вопрос на тему производительности? если у меня все низкоуровневое написано на C++ с OpenCL, а дальше вызывается из Питона, сколько я заплачу за вызов сишных функций из него? Это пикосекунды, микросекунды или миллисекунды?
Просто думаю прикрутить его в проект для упрощения всего высокоуровневого попозже, но надо решить до какой степени его можно использовать.
Ну и, в целом, питон VS луа VS тцл, где будет наименьший оверхед при вызове сишных функций?
Просто думаю прикрутить его в проект для упрощения всего высокоуровневого попозже, но надо решить до какой степени его можно использовать.
Ну и, в целом, питон VS луа VS тцл, где будет наименьший оверхед при вызове сишных функций?
Вот здесь небольшой бенчмарк.
P.S. Вы забыли наносекунды. Нано! Не отстаём от тренда.
P.S. Вы забыли наносекунды. Нано! Не отстаём от тренда.
Спасибо за бенчмарк. Правда мне интересно немного другое, все вычисления сложные будут делаться в си, но вот вызываться сишные функции могут много много раз, поэтому интересно именно сколько я плачу за вызов.
PS: моя ошибка, там должны были быть наносекунды вместо пикосекунд, а то как-то не очень современно:) (да и невозможно)
PS: моя ошибка, там должны были быть наносекунды вместо пикосекунд, а то как-то не очень современно:) (да и невозможно)
Виноват, неправильный бенчмарк Вам показал, хотя этот вопрос меня самого занимал (слегка так).
Исправляюсь:
1. кладём в директорию 3 сущности: benchmark.py, pyc.c, build-extension.py
2. делаем build-extension.py build
3. получим еще директорию, рекурсивно ищем в ней pyc.so, или что-то наподобие. Это наш новый python-модуль, который мы будем сейчас бенчмаркать.
4. запускаем benchmark.py, инедоумённо смотрим на результат:
pavel@spym-pc$ ./benchmark.py
no-load loop period: 42 nsec
function invocation time [nsec]:
c 82
py 107
Что мы видим:
— вызов пустой функции* внутри вызывающего модуля (Python) — 107 наносекунд;
— вызов пустой функции во внешнем нативном модуле © — 82 наносекунды.
* пустая функция — функция, не принимающая аргументов, и возвращающая None.
Честно, я сначала удивился; но спустя пару миллиардов наносекунд осознал, что результат предсказуем.
Дело в том, что нативные модули являются ни чем иным, как нативными динамическими библиотеками — что обеспечивает околонулевой оверхед передачи управления из скрипта в них.
Вобщем, RTFM.
P.S. результаты получены под Slackware64 на Core i7; если кто-то решит повторить, поделитесь своими результатами здесь.
P.P.S только у меня имеются периодические проблемы с доступностью хабра?
Исправляюсь:
1. кладём в директорию 3 сущности: benchmark.py, pyc.c, build-extension.py
2. делаем build-extension.py build
3. получим еще директорию, рекурсивно ищем в ней pyc.so, или что-то наподобие. Это наш новый python-модуль, который мы будем сейчас бенчмаркать.
4. запускаем benchmark.py, и
pavel@spym-pc$ ./benchmark.py
no-load loop period: 42 nsec
function invocation time [nsec]:
c 82
py 107
Что мы видим:
— вызов пустой функции* внутри вызывающего модуля (Python) — 107 наносекунд;
— вызов пустой функции во внешнем нативном модуле © — 82 наносекунды.
* пустая функция — функция, не принимающая аргументов, и возвращающая None.
Честно, я сначала удивился; но спустя пару миллиардов наносекунд осознал, что результат предсказуем.
Дело в том, что нативные модули являются ни чем иным, как нативными динамическими библиотеками — что обеспечивает околонулевой оверхед передачи управления из скрипта в них.
Вобщем, RTFM.
P.S. результаты получены под Slackware64 на Core i7; если кто-то решит повторить, поделитесь своими результатами здесь.
P.P.S только у меня имеются периодические проблемы с доступностью хабра?
Спасибо большое за такой развернутый ответ!
Еще маленький вопрос: если я внутри сишного кода выделяю память, в том числе память на видеокарте, могу ли я вернуть указатели на нее питону, чтобы их можно было использовать при вызове других сишных функций? Надо копать в сторону Capsule?
Еще маленький вопрос: если я внутри сишного кода выделяю память, в том числе память на видеокарте, могу ли я вернуть указатели на нее питону, чтобы их можно было использовать при вызове других сишных функций? Надо копать в сторону Capsule?
Вернуть указатель Вы, конечно, можете: если используете 2.x, то делаете простое приведение значения указателя к python int; если 3.x — примените Capsule.
Вообще слова о Capsule заставляют меня подозревать Вас в использовании Py3k, в то время как я делал бенчмарк для 2.x.
Вообще слова о Capsule заставляют меня подозревать Вас в использовании Py3k, в то время как я делал бенчмарк для 2.x.
Интересно, спасибо. А как при встраивании можно давать пользовательскому коду на питоне доступ к управлению программой? Например, что-то такое:
Вот каким образом должна быть реализована функция get_app_object, что она должна возвращать, и как должен быть устроен метод set_title? Просто интересно в двух словах :)
app_object = get_app_object()
app_object.set_title('tralala')Вот каким образом должна быть реализована функция get_app_object, что она должна возвращать, и как должен быть устроен метод set_title? Просто интересно в двух словах :)
1. встраиваете интерпретатор в приложение;
2. реализуете Вашу функцию get_app_object();
3. создаёте таблицу функций, в которой указываете get_app_object();
4. импортируете приложение с таблицей функций в контекст встроенного интерпретатора;
5. profit! теперь можно вызывать нативный код из скрипта.
RTFM.
2. реализуете Вашу функцию get_app_object();
3. создаёте таблицу функций, в которой указываете get_app_object();
4. импортируете приложение с таблицей функций в контекст встроенного интерпретатора;
5. profit! теперь можно вызывать нативный код из скрипта.
RTFM.
Sign up to leave a comment.
Используем Python в своей программе