[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  

	def slot(combovalue):
		if somedict.has_key(combovalue):
			print "You selected the value", combovalue
			print "Validation error!"

	q = QComboBox()

> 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