[PyQt] chain signals, disconnecting an "emit" slot

[Luke Lee]

Hi Phil,

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.

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!



On Tue, Apr 16, 2013 at 5:29 AM, Phil Thompson
<phil at riverbankcomputing.com>wrote:

> On Mon, 15 Apr 2013 11:02:19 -0500, Luke Lee <durdenmisc at gmail.com> wrote:
> > As mentioned here,
> >
> http://www.riverbankcomputing.com/pipermail/pyqt/2011-October/030578.html,
> > you cannot use the 'disconnect' method to disconnect something when the
> > signals were connected via the emit() method.
> >
> > I'm curious about the details of why connecting signals to the emit()
> > method does not work.  I've tried to do some debugging myself, but I'm
> > still a bit confused.
> >
> > It looks as though the pyqtSignal object **changes** during the course
> of a
> > running application.  For example, consider the following line:
> >
> > ok.pressed.connect(cancel.pressed.emit)
> >
> > As previously mentioned doing a disconnect like the following doesn't
> work:
> >
> > ok.pressed.disconnect(cancel.pressed.emit)
> >
> > I've tried debugging by printing the id() of the cancel.pressed object
> > (pyqtSignal) as well as the id() of the cancel.pressed.emit method.
> These
> > object ids actually **change** between when I connect and later try to
> > disconnect.
> >
> > I've verified that I'm not deleting the objects, etc.  Also, calling
> > cancel.pressed.emit() works as you can imagine even though it's
> seemingly a
> > different object than the one that was connected earlier.  What exactly
> is
> > happening here?
> >
> > I'm assuming it has something to do with the wrapping of the C++ code
> and
> > maybe the QMetaObject
> (http://qt-project.org/doc/qt-4.8/qmetaobject.html)
> > is involved somehow.
> >
> > I'm really just trying to understand why these ids don't match up and
> why
> > connecting signals to signals is preferred vs. connecting to the emit
> > method.  I can easily change my code to connect the signals via the
> > preferred method, but I felt like there was a useful lesson to learn
> here.
> >  Thoughts?
>
> Signals work in a similar way to class methods. A signal object is an
> attribute of a class, not an attribute of an instance of the class. When
> you refer to a signal as an instance attribute a bound signal object is
> automatically created and returned. Normally this will then be garbage
> collected as soon as it is used. The pyqtSignal object doesn't change,
> instead you are seeing different pyqtBoundSignal objects. Unbound and bound
> methods work in the same way.
>
> Connecting to emit doesn't work because of the transitory nature of
> pyqtBoundSignal objects. Connecting to bound methods does work because SIP
> has explicit support for it - SIP doesn't known anything about new-style
> signals.
>
> I could "fix" this, but I'm not going to. Connecting signals to signals is
> the Qt way of doing things and is much more efficient.
>
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20130416/4fa87556/attachment.html>