[PyQt] simpler 'connect' function
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
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