I was going to implement the "warning when connecting with the default signal signature" feature, but I think it doesn't pay off.
In Python all the QObject-derived objects contain a list of signal objects, those signals have a "connect" method and implement the "__getitem__" method of the mapping protocol. When one uses: > obj.signal.connect(...) He is calling the "connect" to the first item on the list of signal overloads called "signal", which is determined at generation time. On the other hand, using > obj.signal[bool].connect(...) Calls "__getitem__(bool)" on the signal object, which returns the specific "signal(bool)" object, which could or could not be the default "signal" object. With this object in hand, "connect" is called for it. In both cases "connect" has no way to know how its "self" object was obtained. Adding a flag "fromDefault" to the signal structure, and set to "false" for the signal objects returned by "__getitem__" wouldn't work, for the returned objects are always the same ones with the reference increased. This for example wouldn't work if "signal(bool)" is also the default signal: > sig = obj.signal[bool] > obj.signal.connect(...) > sig.connect(...) The second line would fail to emit the "you're calling a default signal!" warning, for the "signal(bool)" object was marked as "false" because of the first line. The fix for the solution would be to return an entirely new signal object every time "__getitem__" is called. But that would get the thing more complex and consume more resources. I think that's too much of a hassle just to emit a warning. A better solution would be to add the needed information to the documentation and trust the developers common sense. :) On Mon, Dec 13, 2010 at 3:18 PM, Marcelo Lira <[email protected]> wrote: > After my fix the test "signals/signal_signature_test.py" stopped > working, exactly here: > >> sender.destroyed.connect(callback) >> self.assertEqual(sender.signal, SIGNAL('destroyed(QObject*)')) > > The signal is defined as "destroyed(QObject* = 0)", which means that > you'll have two signals: "destroyed()" and "destroyed(QObject*)". > One would expect that "sender.destroyed.connect(...)" would connect > the signal version without any arguments. And as I told before, > without the fix the user can't even force it with > "sender.destroyed[None].connect(...)". > > I fixed the test as follows: > >> sender.destroyed.connect(callback) >> self.assertEqual(sender.signal, SIGNAL('destroyed()')) > >> sender.destroyed[QObject].connect(callback) >> self.assertEqual(sender.signal, SIGNAL('destroyed(QObject*)')) > > I think this connection semantics makes more sense. > > On Mon, Dec 13, 2010 at 2:53 PM, Matti Airas <[email protected]> wrote: >> Hi, >> >> In my opinion, the PSEP proposal should be withdrawn because it's a sure >> recipe for future breakage (as Renato pointed out). I didn't take any action >> on it yet because I received no comments on the previous mails regarding the >> topic. >> >> As discussed offline with Marcelo, my proposal is that if you connect to the >> default signature of overloaded operators, you should get a warning printed >> out on STDERR but do nothing else. That way, developers would get a heads-up >> for potentially difficult-to-catch bugs but we wouldn't break any existing >> code now or in the future. >> >> As for Marcelo's commit, we had a discussion about it and while it >> (theoretically) breaks some existing code, the existing behaviour was pretty >> unobvious and probably could've been regarded a bug in the first place. I >> prefer the new (fixed) semantics. >> >> Marcelo, could you recap the breaking test? >> >> Cheers, >> >> ma. >> >> On 13.12.2010 14:01, ext Marcelo Lira wrote: >>> >>> In other thread[1] Christian reported that the right >>> QAbstractButton.clicked signal failed to connect with lambda and >>> partial functions. >>> Since the signal signature is "clicked(bool = false)" one would >>> suppose that "button.clicked.connect(...)" would connect to the >>> "clicked()" version of the signal. But due to a generation error not >>> even explicitly connecting to it with >>> "button.clicked[None].connect(...)" would work. >>> >>> I fixed the problem in the commit Shiboken/33537a0e, which will >>> register the signatures "clicked()" and "clicked(bool)", instead of >>> just the latter. I wasn't unaware, but my fix could interfere with >>> what is discussed with this PSEP. >>> >>> I need your comments on my change. If it should be reverted and put on >>> a branch for future use after some decision is made regarding the >>> signal behavior, or just leave it on HEAD as it is. >>> >>> On Fri, Nov 26, 2010 at 10:13 AM, Matti Airas<[email protected]> >>> wrote: >>>> >>>> On 24.11.2010 20:43, ext [email protected] wrote: >>>> >>>>> As another approach to dealing with the problem of undefined default >>>>> signatures, could we just print a warning whenever the default signature >>>>> is >>>>> used for overloaded signals? This would have no effect on PySide >>>>> semantics, >>>>> and would, in my opinion, not even require a PSEP. >>>> >>>> What's the opinion on this one? Would this approach sufficiently solve >>>> the >>>> issue? >>> >>> >>> >>> >>> [1] http://lists.openbossa.org/pipermail/pyside/2010-December/001610.html >> >> > _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
