[PyQt] Proposal for New-style Signals
David Boddie
david at boddie.org.uk
Thu Jan 24 00:24:32 GMT 2008
On Mon, 21 Jan 2008 15:20:16 +0000, Phil Thompson wrote:
> I plan to make changes in two stages.
>
> Stage 1
[...]
> Question: It would be possible to allow (but not require) short-circuit
> signals to be predefined using __pyqtSignals__. [dis]connect() and emit()
> could then check the name (but not any arguments) of the signal. A check
> would only fail if at least one short-circuit signal had been defined (to
> preserve backwards compatibility). Is this worthwhile? (My feeling is
> no.)
It would be nice to be able to list short-circuit signals, but it's not
that important.
> Stage 2
[...]
> For example:
>
> btn.clicked[''].connect(self.on_clicked)
> btn.clicked['bool'].connect(self.on_clicked_checked)
>
> btn.toggled['bool'].emit(True)
>
> In addition, for signal overloads with no arguments (ie. with '' as the
> signal key) the index can be omitted as follows:
>
> btn.clicked.connect(self.on_clicked)
>
> Note that for a signal with at least one argument, but without an overload
> that has no arguments, this "short form" is invalid. This is to allow for
> the addition of a no-argument overload some time in the future.
I still can't see the attraction of this syntax. I sort of see the point
of things like
button.clicked.emit()
but the stage 2 connect syntax looks inside-out.
I thought that one of the main points behind adding extra syntax was to
reduce the amount of redundancy, so you could allow things like
self.connect(SIGNAL("valueChanged(int)"), spinBox.setValue)
removing the unnecessary "self" argument, or even
self.connect("valueChanged(int)", spinBox.setValue)
OK, so there's still the potential to make mistakes with strings, but
you could introduce some kind of checking, either within the SIGNAL()
function or as part of the connect() call.
Maybe I missed the point of this discussion. :-/
David
More information about the PyQt
mailing list