[PyQt] simpler 'connect' function

Aaron Digulla digulla at hepe.com
Wed Jan 16 08:21:40 GMT 2008

Quoting Peter Shinners <pshinners at blizzard.com>:

>> That's why I'm against string literals in an API. If that API doesn't
>> even offer any checks to string literals, that's even worse.
> I'd be against using constants to define the signals. What type of value
> is going to match things like "const QString&"?
> How can Pyqt possibly check that the given callback accepts the type of
> arguments requested?

You're missing my point: I try to reduce the amount of typos. If all  
signals in Qt were predefined constants in PyQt, then a typo would  
result in "attribute not found" exceptions when they are defined  
instead of volatile "doesn't work" bugs when they are used for the  
first time.

I'm not trying to fix signals defined by other frameworks which extend  
Qt nor ones written by PyQt developers. If they want to waste their  
time hunting typos, I'm cool with that. Everyone has the right to make  
their lives as miserable as they want.

As for making the API simpler, I'd opt for


I think that would be the most simple API possible which still

a) doesn't introduce ambiguity (you can't omit the "connect"),
b) contains the two objects to connect,
c) makes sure which one "sends" and which one "receives" in the  
right/intuitive way (i.e. in the way most of the people think),
d) allows to catch typos,
e) allows to check argument types,
f) allows to use auto-completion and
g) is backward compatible.

Your proposed change doesn't fit d) to g). If you still think it's a  
good idea, you can always try to implement it (just do  
QPushButton.connect = ...) and after a while, you'll see how it's bad.


Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."

More information about the PyQt mailing list