[PyQt] Proposal for New-style Signals

[Phil Thompson]

On Thursday 24 January 2008, David Boddie wrote:
> 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.

Because it's focused on the sender rather than the receiver? Your suggestion 
below does as well.

> 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)

If this has been suggested before then I missed the subtlety of it. I will add 
that to stage 1.

> 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.

It will raise an exception if the signal doesn't exist

> Maybe I missed the point of this discussion. :-/

One reason for splitting the proposal into two stages was that the first stage 
is relatively easy to implement. I'm not making any statements about when the 
second stage might be implemented.

Phil