[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