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
