<div dir="ltr">Hi Phil,<div><br></div><div>Thanks for the information.  That all makes perfect sense.  I've been migrating my code from connecting signals with emit and was just curious about the technical details.</div>
<div><br></div><div style>I agree this isn't worth 'fixing,' I wouldn't consider it a bug.  It's nice to get a little more insight into the fundamentals though!</div><div style><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 5:29 AM, Phil Thompson <span dir="ltr"><<a href="mailto:phil@riverbankcomputing.com" target="_blank">phil@riverbankcomputing.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, 15 Apr 2013 11:02:19 -0500, Luke Lee <<a href="mailto:durdenmisc@gmail.com">durdenmisc@gmail.com</a>> wrote:<br>
> As mentioned here,<br>
><br>
<a href="http://www.riverbankcomputing.com/pipermail/pyqt/2011-October/030578.html" target="_blank">http://www.riverbankcomputing.com/pipermail/pyqt/2011-October/030578.html</a>,<br>
> you cannot use the 'disconnect' method to disconnect something when the<br>
> signals were connected via the emit() method.<br>
><br>
> I'm curious about the details of why connecting signals to the emit()<br>
> method does not work.  I've tried to do some debugging myself, but I'm<br>
> still a bit confused.<br>
><br>
> It looks as though the pyqtSignal object **changes** during the course<br>
of a<br>
> running application.  For example, consider the following line:<br>
><br>
> ok.pressed.connect(cancel.pressed.emit)<br>
><br>
> As previously mentioned doing a disconnect like the following doesn't<br>
work:<br>
><br>
> ok.pressed.disconnect(cancel.pressed.emit)<br>
><br>
> I've tried debugging by printing the id() of the cancel.pressed object<br>
> (pyqtSignal) as well as the id() of the cancel.pressed.emit method.<br>
These<br>
> object ids actually **change** between when I connect and later try to<br>
> disconnect.<br>
><br>
> I've verified that I'm not deleting the objects, etc.  Also, calling<br>
> cancel.pressed.emit() works as you can imagine even though it's<br>
seemingly a<br>
> different object than the one that was connected earlier.  What exactly<br>
is<br>
> happening here?<br>
><br>
> I'm assuming it has something to do with the wrapping of the C++ code<br>
and<br>
> maybe the QMetaObject<br>
(<a href="http://qt-project.org/doc/qt-4.8/qmetaobject.html" target="_blank">http://qt-project.org/doc/qt-4.8/qmetaobject.html</a>)<br>
> is involved somehow.<br>
><br>
> I'm really just trying to understand why these ids don't match up and<br>
why<br>
> connecting signals to signals is preferred vs. connecting to the emit<br>
> method.  I can easily change my code to connect the signals via the<br>
> preferred method, but I felt like there was a useful lesson to learn<br>
here.<br>
>  Thoughts?<br>
<br>
</div></div>Signals work in a similar way to class methods. A signal object is an<br>
attribute of a class, not an attribute of an instance of the class. When<br>
you refer to a signal as an instance attribute a bound signal object is<br>
automatically created and returned. Normally this will then be garbage<br>
collected as soon as it is used. The pyqtSignal object doesn't change,<br>
instead you are seeing different pyqtBoundSignal objects. Unbound and bound<br>
methods work in the same way.<br>
<br>
Connecting to emit doesn't work because of the transitory nature of<br>
pyqtBoundSignal objects. Connecting to bound methods does work because SIP<br>
has explicit support for it - SIP doesn't known anything about new-style<br>
signals.<br>
<br>
I could "fix" this, but I'm not going to. Connecting signals to signals is<br>
the Qt way of doing things and is much more efficient.<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil<br>
</font></span></blockquote></div><br></div>