[PyQt] Proposal for New-style Signals

[Phil Thompson]

On Wednesday 23 January 2008, Andy Davidoff wrote:
> On Jan 21, 2008 10:20 AM, Phil Thompson <phil at riverbankcomputing.com> wrote:
> > Question: An alternative approach would be to define a "default" signal
> > (in the .sip files) which would identify the overload to be used with the
> > "short form".  As most Qt signals aren't overloaded this would mean that
> > the type string would not have to be specified in the majority of cases. 
> > Is this worthwhile? (My feeling is yes.)
>
> -1 not pythonic, less legible, could create/hide bugs, later
> compatibility issues

The design guarantees no future compatibility problems. What do you mean 
by "could create/hide bugs"?

> Although I don't use an IDE or code completion, I would still prefer a
> more explicit type string over an implicit one.  I'd rather the code
> was more legible and I believe it could even help the developer catch
> type errors earlier, especially when working with someone else's code.
>
> As the "default" would need to be documented and taught, and because
> there will be cases where the default may not be used, we will end up
> with new code which uses both styles.  This seems confusing for new
> developers and again, less legible.
>
> When a new version of Qt/PyQt deprecates or changes the default signal
> types, does the semantics of the "default" syntax change in code
> written for an earlier version?

A change in default would be an API change, and so wouldn't happen because 
backwards compatibility (for both Qt and PyQt) is a requirement.

> If the earlier syntax is supported along with this new syntax, there
> are in effect three (or more) ways to write the same expression, of
> which a new developer should know at least two.  This may be a
> "feature" in perl, but I believe it is generally frowned upon in
> Python.

About 4% of signals are overloaded. I think your point would be an issue if 
that proportion was significantly higher, ie. if a newbie would be likely to 
come across both short and long forms in, say, the tutorials.

Of the overloaded signals, none of the overloads are obvious candidates for 
being the default - so in those cases there would be no default and the long 
form would have to be used. In fact the only use of the "default" flag would 
probably be to preserve backwards compatibility in the event of a later 
version of Qt introducing a new overload.

> Just one opinion, and the rest of your proposal seems like a good step
> forward to me.

Phil