[PyQt] pyqtSlot

[oliver]

On Thu, Aug 25, 2016 at 11:25 AM, Phil Thompson <phil at riverbankcomputing.com
> wrote:

> On 25 Aug 2016, at 2:24 pm, oliver <oliver.schoenborn at gmail.com> wrote:
> >
> >
> >
> > On Thu, Aug 25, 2016 at 8:40 AM, Phil Thompson <
> phil at riverbankcomputing.com> wrote:
> >
> > Inspect the QMetaObject to see if the slot is there as you would expect.
> >
> > >
> > > If the slot weren't in the QMetaObject, how would the object method
> > > get called (it does get called)?
> >
> > The same way any other type of callable is handled, by creating a proxy
> QObject when the connection is made.
> >
> >
> > The slot will surely be in the wrapper's proxy QObject.QMetaObject
>
> No it won't, that's not how the proxy works.
>
> > but what's the concern with that? As long as the connection is
> established from the correct thread, the proxy QObject will be owned by the
> correct thread so the proxy slot will be called in the correct thread, and
> this in turn will call the slot_wrapper which will call our QObject's
> method. Should all be good, no?
>
> But why bother with pyqtSlot at all if you don't care about it being in
> the QMetaObject?
>
> Phil


I got the impression from somewhere on the web that cross-thread signaling
is safer in Python if you use pyqtSlot decorator, may that's a couple years
ago so maybe I'm remembering wrong. The real reason is probably that the
docs on Riverbank say "Connecting a signal to a decorated Python method
also has the advantage of reducing the amount of memory used and is
slightly faster.".

Can you provide some details about when using pyqtSlot is really
beneficial? Are you implying that I should be able to remove all uses of
pyqtSlot (as decorator or, like I showed in example above, as wrapper) from
our code and the code should run identically, except for extra memory and
slower speed (likely not noticeably slower because we don't have a thread
that emits huge numbers of signals)?

Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20160825/966c2f3d/attachment.html>