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

Luke Lee durdenmisc at gmail.com
Tue Apr 16 15:27:03 BST 2013

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>

More information about the PyQt mailing list