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
