Fwd: Python Signal/Slot + QThred code analysis

Michael Torrie torriem at gmail.com
Fri Nov 28 01:52:45 CET 2014

On 11/27/2014 04:29 PM, Juan Christian wrote:
> So, instantly I found one issue, you said that this code won't block the
> GUI, only the thread event loop, but if we keep moving the window while
> it's open, every time new info is printed the GUI freezes for like 1-2
> seconds.

Correct.  The thread does not block the GUI.  I cannot replicate your
problem on my machine here. Maybe we're finding a problem with Windows
and Qt.  I can drag the window around and it keeps on a going.

> And why this approach of a single instance is better? I mean, I'll have to
> call Outpost every time I get new data from my other API, because there
> will be different users, so I need to create different instances so I call
> the site with a new ID, don't I?

Just seems wasteful, that's all.  Why not instantiate Outpost from the
worker thread?  Especially if your thread only does one thing every 5
seconds.  Starting up a new thread and destroying seems like a waste.
But it certainly can be done that way.

> Maybe the answer for that question is that you using a timer that is ALWAYS
> active and ALWAYS calling the the outpost site, so I'll have something like:
> var = Outpost('12345')
> var.posts -> 100
> var.setID('67893')
> var.posts -> 35
> Is that right? But I don't think that always calling the site this way is
> good for them and for me, sometimes I may not get new users for like 10~15
> minutes, so I would have wasted a lot of calls for nothing. That's why I
> only instantiate/call the site when I get new users.

I was simply using the logic you originally provided. I have no idea
what Outpost does or how you use it.  Your original code just grabbed
some data every 5 seconds, so that's what I got it to do in the most
efficient way.  You'll have to adapt it to your real needs.

More information about the Python-list mailing list