[PyQt] Proposal for New-style Signals
Andy Davidoff
andy.davidoff at pobox.com
Thu Jan 24 13:30:12 GMT 2008
On Jan 24, 2008, at 5:27 AM, Phil Thompson wrote:
> 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.
It's not explicitly clear where the error is in the code below, or
even if there is an error, since I have no idea which type list is the
default...
def slot(combovalue):
if somedict.has_key(combovalue):
print "You selected the value", combovalue
else:
print "Validation error!"
q = QComboBox()
q.currentIndexChanged.connect(slot)
> 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.
Which of the overloaded currentIndexChanged, activated, or highlighted
signals on QComboBox, for example, are obviously not candidates for
being the default?
Honestly, the fact that the default is not guaranteed to always be
usable sounds worse.
Will there be any way to discover the default and/or exposed signals
via reflection?
More information about the PyQt
mailing list