Вышел PyQt v4

Поздравляю!!! Будем тестить :-)

Qt рулит, а PyQt не понравился. Может потому что на C++ привычней писать.

Доки очень мутные

тролевский референс подходит

По идее, после с++ python должен казаться очень простым удобным и изящным...

> По идее, после с++ python должен казаться очень простым удобным и изящным...

О, да! Оцените верх изящества:

QtCore.QObject.connect(a, QtCore.SIGNAL("finished(int)"), QtCore.SLOT("done(int)"))

Чисто C++-сигнатуры функций в питоновском коде - красота. Это еще мелочи, кстати, а то там и всякие QObject& могут вылезти...

Кстати, у QtRuby та же беда. Ну не предназначен Qt для вызова из других языков просто...

>QtCore.QObject.connect(a, QtCore.SIGNAL("finished(int)"), QtCore.SLOT("done(int)"))

а зачем так страшно?

from QtCore import * сделает данную строчку намного проще...

Я знаю, как в питоне работает неймспейсинг. К этому у меня претензий и не было. Но что делают в питоновском коде описания прототипов функций на C++?

Не надо преувеличивать. В большинстве случаев достаточно такого кода: connect(a, SIGNAL("finished"), a.done). Если это для Вас сложно, могу порекомендовать Дельфи. :P

ну "finished(int)" это просто имя сигнала, наследие moc

А есть какие-то другие идеи, как вытащить сигналы и слоты из Qt?

здорово, для поделок самое оно.

а вот для немного более сложных вещёй косяки тут и там, например:цепляем сигнал к слоту завязанному на гуй, испускаем сигнал в негуёвом треде и получаем геморрой:

Xlib: unexpected async reply (sequence 0x1306)!

имеем: слот вызывается в негуёвом треде как и сказано в описании:

The Signals and Slots mechanism can be used in separate threads, as long as the rules for QObject based classes are followed. The Signals and Slots mechanism is synchronous: when a signal is emitted, all slots are called immediately. The slots are executed in the thread context that emitted the signal.

Warning: Slots that generate window system events or use window system functions must not be connected to a signal that is emitted from a thread that is not the GUI thread. See the Qt Library Mutex section above for more details.


Сигналы по жизни единственное средство для асинхронного взаимодействиа, а в этом поделии с мощным названием "The Signals and Slots mechanism", ёлы, их фундаментальное свойство похерили, тьфу...

> А есть какие-то другие идеи, как вытащить сигналы и слоты из Qt?

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

Хотя, в QtRuby что-то такое обещают...

Доку читать пробовали?

> Доку читать пробовали?

Собсно оттуда цитату и привёл, из описания кутёвых тредов. Троллям не надо было свои сигналы называть сигналами, поскольку любой использующий IPC знает, что сигналы - единственное средство асинхронной передачи сообщений, а тролли передачу сообщения назвали испусканием сигнала в своей _синхронной_ хрени, чем запутывают редиски.

Если я не так вас понял, просьба объясниться с указанием линков на незамеченные мной доки.

> Сигналы по жизни единственное средство для асинхронного взаимодействиа, а в этом поделии с мощным названием "The Signals and Slots mechanism", ёлы, их фундаментальное свойство похерили, тьфу...

Для асинхронного взаимодействия есть множество средств: семафоры, очериди, мютексы, трубы, в конце концов. Вообще, питон не создан для асинхронных приложеный.

> Для асинхронного взаимодействия есть множество средств: семафоры, очериди, мютексы, трубы, в конце концов.

Нет, для асинхронного обмена есть только одно средство - сигналы. Любое асинхронное средство должно давать возможность заставить принимающую сторону обработать сообщение в _произвольной_ точке выполнения с помощью обработчика, а не принимать эти сообщения на блокирующем вызове или периодически на неблокирующем.

> Вообще, питон не создан для асинхронных приложеный.

Совершенно верно, это "косяк" питона, http://docs.python.org/lib/module-signal.html :

Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal() operations in the main thread of execution. Any thread can perform an alarm(), getsignal(), or pause(); only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). This means that signals can't be used as a means of inter-thread communication. Use locks instead.