[PyQt] simpler 'connect' function

[Peter Shinners]

Aaron Digulla:
> 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.

Ah, I misunderstood what you meant by type checking then.

In then end, I think I'd still prefer the strings. It still feels like a
more direct translation of what is going on in C++.

The constants get more tricky when SIPping custom widgets that aren't
part of Qt and have their own signals. If each signal was an attribute
on each instance it might be easier for binding.


> 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).

A method version of connect, called directly from instances, is
backwards compatable. This is important and I wouldn't propose anything
that would break this ("g"). 

Checking argument types ("e") is still not possible. Using methods to
connect signals helps no more than the current connect function. 

Creating a method or constant for each type of signal does solve "d" and
"f", but comes at a cost.

1) Adds new methods or symbols that are not a part of Qt.
2) Breaks non-qt widgets that have custom signals.
3) Ambiguity for overloaded signals like QComboBox's "activated".

There is no cost to enhancing connect to work as a method, other than
remembering there is another calling style.