[PyQt] Proposal for New-style Signals
phil at riverbankcomputing.com
Thu Jan 24 10:27:53 GMT 2008
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
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.
More information about the PyQt