FishHookПитон не для этого, забудь о гуёвых приложениях на питоне. Его ниша - веб, админские скрипты, математические или научный вычисления.
Зря ты так... Питон также, занимает огромную нишу в VFX-индустрии в качестве стандарта скриптового языка. В проекте, над которым я работаю уже больше 2-ух лет, используется, как раз, Python в связке с PySide для скриптинга (само приложение написано на C++ с Qt и ещё кучей либ). Пользователи абсолютно прозрачно могут кастомизировать бизнес-логику приложения, добавлять новые UI элементы, убивать существующие, менять их поведение, навешивать новые хендлеры уже на существующие контролы и так далее.

FishHookЛично я не рекомендую питон для ГУИ ввиду личного негативного опыта.
Можно по-подробнее, с этого места?

FishHookя с питоном на "ты" уже довольно давно, больше 5-ти лет
Примерно, столько же.

FishHookКутэшные программы я буду писать на плюсах.
Логично, но есть вещи, в которых ты хочешь дать пользователю решать как программа будет себя вести. И вместо выставления C/C++ интерфейсов, гораздо проще и эффективнее использовать Путхон.
Конечно, можно сказать, что в Qt есть модуль JS, но это, пожалуй ещё хуже в качестве UI-скриптинга.

Areostar,

Тебе уже предоставили ссылочку. Если мучаешься между выбором PySide или PyQt, выбирай второе. Насчёт других, ничего не могу сказать.

FishHookГлюки, тормоза PyQT (конкретно у меня это выражалось в мерцании фона кастомных кнопок, аналогичный код на плюсах работал без проблем), невнятная документация (по сравнению с родной).

Не знаю, если вы всё через QSS делали, то везде должно быть одинаково, либо какой-то лишний хэндлер при перерисовке был. Там ведь никакой магии нет. В любом случае, для этого есть багтрекер и это не повод так громко делать подобные выводы.

FishHookВ каком плане проще? ИМХО всё-таки проще получить ошибку при компиляции, чем ловить плавающий баг.

Проще, что пользователям не нужно напрягаться, настраивать у себя гарантированное разработчиком сборочное окружение, только лишь для того чтобы добавить пару кнопочек в программу. Какая разница на каком языке пользователь расширяет данную ему программу -- везде одинаковые возможности даны, вопрос лишь в удобстве этого процесса для конечного пользователя.

FishHookВы же понимаете, что питонья программа попадает в продакшен, только если покрыта тестами на 100%, иначе это мешок потенциальных глюков. Ну а автоматическое тестирование гуёвой программы, это сама по себе задача объемная и сложная. Простота питона тут эфемерна.

Не, я сказал, что программа написана на C++ и Qt, её GUI -- не исключение. Питоновые скрипты НЕ попадают в продакшн.
Питон относится к программе, как VBA к MS Excel.
С программой распространяется питоновое окружение, libpython, нативные модули для доступа к бизнес-логике и PySide.
Все возможные сценарии с бизнес-логикой тестируются в непрерывной интеграции. А вот GUI -- всё полностью возлагается на пользователя. Поскольку, питоновый код выполняется в контексте самой C++ программы, то из питона сразу доступны и экземпляр QApplication, и всё дерево виджетов. В программе есть встроенный редактор скриптов + кастомный init.py скрипт выполняется из home директории пользователя, в качестве бутстрапа для его кастомных штук (по-умолчанию он пустой), при запуске программы. Если пользователь сам захотел удалить (не скрыть) какой-то виджет и программа повела себя неадекватно -- он сам себе злобный Буратино. То же самое ты можешь сделать, выставив нативные C/C++ интерфейсы. Разве-что больше заморочишься.

FishHookВообще, программа с графическим интерфейсом подразумевает как правило широкий круг заранее неизвестных пользователей. В отличие от веб-решения (а именно в вебе питон хорош), где одна копия программного кода обеспечивает работу тысяч пользователей, и развертывание кода на сервере производится единожды квалифицированными людьми, десктопные приложения порождают ряд дополнительных проблем:
1. Дополнительные зависимости: в отличие от простого .exe файла, для запуска питоньей программы нужен установленный интерпретатор нужной версии, возможно виртуальное окружение, SIP, заголовочные файлы питона и прочее.
2. Для того чтобы всё это предоставить пользователю придется делать нетривиальный инсталлятор. В виде portable-приложения распространять продукт не получится. Юзеру нужны админские права для установки программы.
3. Пользователь работает не со знакомым ему .exe, а с непонятным .py/.pyw
4. Пользователю предоставляются исходники программы.
1. Выше уже описан сценарий без интерпретатора. Достаточно иметь libpython и батарейки. Можно запускать свой exe, который будет поднимать питоновые дела и евалить единственный скрипт. Пользователь этого всего не видит. Так же как и Eclipse IDE, вроде он написан на Java полностью, но запускается из нативного исполняемого файла.
2. Увы, такова реальность ;-)
3. Нет. Как я уже сказал выше, этого можно избежать. Есть ещё вариант использовать тулы, заворачивающие всё окружение питона и твои скрипты в один единственный exe.
4. Тут уж кто на что горазд и каковы цели разработчика.