Quoting Peter Shinners <[EMAIL PROTECTED]>:
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
button.connectClicked(self.buttonWasClicked)
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.
Regards,
--
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."
http://www.pdark.de/
_______________________________________________
PyQt mailing list [email protected]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
