Comments 38
В C# очень легко подключить питон (IronPython).
-2
В C# и подключать то не надо.
У него есть динамическая компиляция, и что важнее, менее замороченный синтаксис. +Серверный программист делился, что C# «на лету» выполняет свой код быстрее подключаемых lua,php,python…
Для С++ смысл это уже имеет…
У него есть динамическая компиляция, и что важнее, менее замороченный синтаксис. +Серверный программист делился, что C# «на лету» выполняет свой код быстрее подключаемых lua,php,python…
Для С++ смысл это уже имеет…
+5
В C# и подключать то не надо. У него есть динамическая компиляция, и что важнее, менее замороченный синтаксис.
Синтаксис или грамматика? А то, с одной стороны, кому важен чистый синтаксис языка? а с другой, называть грамматику C# «менее замороченной» по сравнению с грамматикой Python-а — это, кхм…
+2
я встроил Python в гейм-бота написанного на delphi (stealth.od.ua) =)
правда он бывает крешится :\ не хватает квалификации пофиксить все проблемы
правда он бывает крешится :\ не хватает квалификации пофиксить все проблемы
+1
Хотел бы при случае повторить подобный подвиг. Исходниками делишься?
0
Вы использовали code.google.com/p/python4delphi/?
0
Я пробовал встраивать JavaScript в свой сервер с использованием движка SpiderMonkey (который в Firefox используется), тоже неплохо получилось. Теперь, благодаря вашей статье, захотел встроить Python. Судя по всему, Python встроить даже легче.
+1
Не хотелось говорить, но основной язык программирования в Google С++
+12
Прошу прощения, накатило что то ;) сам использую Python очень много и спасибо за статью.
+1
Сильно громкое заявление.
Разные команды Гугла имеют свои предпочтения и организацию труда, в т. ч. и инструменты. С++ — да, там, где нужна производительность. Но не менее популярны там Java (например, frontend G+ на их сервлет сервере собственном работает) и Python. Есть и другие, но менее используемые (например, Sketchup имеет Ruby API для создания плагинов).
К чему я это. Там люди поступают правильно — стараются брать инструмент под задачу, а не пис++ками меряться и выбирать основной язык)) Поэтому называть С++ основным языком Гугла — не сильно корректно.
Разные команды Гугла имеют свои предпочтения и организацию труда, в т. ч. и инструменты. С++ — да, там, где нужна производительность. Но не менее популярны там Java (например, frontend G+ на их сервлет сервере собственном работает) и Python. Есть и другие, но менее используемые (например, Sketchup имеет Ruby API для создания плагинов).
К чему я это. Там люди поступают правильно — стараются брать инструмент под задачу, а не пис++ками меряться и выбирать основной язык)) Поэтому называть С++ основным языком Гугла — не сильно корректно.
+1
Я правильно понимаю, что питон можно интегрировать во все мыслимые языки программирования?
+1
Ну конечно не во все, но во многие популярные можно.
+1
> При разработке прикладных программ иногда возникает необходимость предоставить пользователю какую-то достаточно гибкую, но простую систему для управления программой…
… Для таких случаев идеально подойдёт Tcl. А когда нужно что-то совсем миниатюрное — Jim.
… Для таких случаев идеально подойдёт Tcl. А когда нужно что-то совсем миниатюрное — Jim.
+1
Тикль в данном случае работает наоборот: выгоднее к нему подключать модули на C/C++, чем его встраивать в программу на C/C++. Как уже выше заметили, идеальный встраиваемый язык — это Lua.
0
То же самое с Python. Embedding (то есть встраивание) порождает очень неприятную болезнь под названием «геморрой», намного более просто и удобно делать extending (пописывая себе подключаемый функционал на С).
0
Как уже отметили выше, Lua ужасен для встраивания и слишком сложен в качестве простой системы управления программой. Разрабатывался как встраиваемый язык, а оказался в одной нише с Python.
0
Вы видимо никогда не пробовали ни встроить, ни использовать. Lua не прост, он элементарен, там спецификации занимают 60кб из которых 70% — просто перечисление доступных функций. Язык в любом случае намного легковеснее и проще, чем Python. А встраивание ничего сложного не представляет: чистый C-api, очень лёгкий и удобный. В одной нише с Python он никогда не был и не будет: мощь Python опирается на титаническую стандартную библиотеку (настолько титаническую, что поговаривают об её обрезании), которой в Lua нет в принципе. Говорю, как работавший с обоими языками.
0
Не осилил найти ссылку. Подскажите сайт Джима?
0
Помнится, горели мы как-то в танке использовал хэнд-мейд фреймворк, который вызывал Py из Delphi, для SQL запросов преимуществ., а еще там был XML где-ж его нет, для создания окошек на лету. Не оправдал полет мысли тим-лида, вложенных средств…
+2
Вообще-то, SWIG (как и SIP) не для встраивания Python в программы на C\C++, а наоборот: для использования кода C\C++ в проектах на Python.
+1
Вообще да. Но скрипты то и применяются для управления С++ кодом. Игровая логика, например. Запускаешь питоновский update, и он уже дергает нужные С++ ф-ии и обновляет состояние нужных объектов. Если взять пример построения графиков из статьи, то по идее в С++ будет ф-ия рисования точек plot(х, у), которая экспортируется в питон. А в питоне уже реализуются мат ф-ии, которые в итоге дергают plot() для построения графика этой мат ф-ии.
+1
UFO just landed and posted this here
Есть вопрос на тему производительности? если у меня все низкоуровневое написано на C++ с OpenCL, а дальше вызывается из Питона, сколько я заплачу за вызов сишных функций из него? Это пикосекунды, микросекунды или миллисекунды?
Просто думаю прикрутить его в проект для упрощения всего высокоуровневого попозже, но надо решить до какой степени его можно использовать.
Ну и, в целом, питон VS луа VS тцл, где будет наименьший оверхед при вызове сишных функций?
Просто думаю прикрутить его в проект для упрощения всего высокоуровневого попозже, но надо решить до какой степени его можно использовать.
Ну и, в целом, питон VS луа VS тцл, где будет наименьший оверхед при вызове сишных функций?
0
Вот здесь небольшой бенчмарк.
P.S. Вы забыли наносекунды. Нано! Не отстаём от тренда.
P.S. Вы забыли наносекунды. Нано! Не отстаём от тренда.
+2
Спасибо за бенчмарк. Правда мне интересно немного другое, все вычисления сложные будут делаться в си, но вот вызываться сишные функции могут много много раз, поэтому интересно именно сколько я плачу за вызов.
PS: моя ошибка, там должны были быть наносекунды вместо пикосекунд, а то как-то не очень современно:) (да и невозможно)
PS: моя ошибка, там должны были быть наносекунды вместо пикосекунд, а то как-то не очень современно:) (да и невозможно)
0
Виноват, неправильный бенчмарк Вам показал, хотя этот вопрос меня самого занимал (слегка так).
Исправляюсь:
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 только у меня имеются периодические проблемы с доступностью хабра?
+1
Спасибо большое за такой развернутый ответ!
Еще маленький вопрос: если я внутри сишного кода выделяю память, в том числе память на видеокарте, могу ли я вернуть указатели на нее питону, чтобы их можно было использовать при вызове других сишных функций? Надо копать в сторону Capsule?
Еще маленький вопрос: если я внутри сишного кода выделяю память, в том числе память на видеокарте, могу ли я вернуть указатели на нее питону, чтобы их можно было использовать при вызове других сишных функций? Надо копать в сторону Capsule?
0
Вернуть указатель Вы, конечно, можете: если используете 2.x, то делаете простое приведение значения указателя к python int; если 3.x — примените Capsule.
Вообще слова о Capsule заставляют меня подозревать Вас в использовании Py3k, в то время как я делал бенчмарк для 2.x.
Вообще слова о Capsule заставляют меня подозревать Вас в использовании Py3k, в то время как я делал бенчмарк для 2.x.
0
Интересно, спасибо. А как при встраивании можно давать пользовательскому коду на питоне доступ к управлению программой? Например, что-то такое:
Вот каким образом должна быть реализована функция get_app_object, что она должна возвращать, и как должен быть устроен метод set_title? Просто интересно в двух словах :)
app_object = get_app_object()
app_object.set_title('tralala')
Вот каким образом должна быть реализована функция get_app_object, что она должна возвращать, и как должен быть устроен метод set_title? Просто интересно в двух словах :)
0
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.
+1
Sign up to leave a comment.
Используем Python в своей программе