What is the status of this project?

[Kentzo]

I'd like to participate in development. What are problems that need to be solved?

[harvimt]

Well there's this PR (#29) that I haven't decide whether I should merge yet. Or if I should use a sys.modules hack instead.

Also we need an EventLoopPolicy that creates one QEventLoop per-thread.

Then the QThreadExecutor needs to be able to take a coroutines or functions.

Also test coverage.

Maybe some examples?

[Kentzo]

How about support of different OSes? Is that part done well?

[harvimt]

It hasn't been tested on OS X, but it should work.

Windows & Linux (really anything with a select including OS X) should work just fine.

[Kentzo]

Also we need an EventLoopPolicy that creates one QEventLoop per-thread.

Do you mean python threads or Qt threads here?

[harvimt]

it's issue #26

One QEventLoop per QThread.

And that's actually one of the issues. I'm not sure if there's a way to tell whether the current thread is a QThread or a threading.Thread (since under the hood they're OS Threads).

[harvimt]

Travis supports Mac OS X CI, but not with Python, so a Travis for Mac configuration that tested Quamash on OS X would also be nice to have.

[Kentzo]

I'm pretty sure you cannot use QThread and threading.Thread interchangeably. Maybe we could use QThread.currentThread to determine whether thread is managed by Qt… In other hand library shouldn't really force usage of QThread over threading.thread

I've seen some env-based loading in the lib. Why is it so? In my application I would have to remove it for security concerns…

[harvimt]

You actually totally can (since they're both based on OS Threads), but only QThreads can receive signals. As a corollary QObjects can only be granted affinity to QThreads. In practice then it's highly impractical to not use QThreads when you're using PyQt.

QThread.currentThread returns the OS thread ID though:

    threading.Thread(target=lambda: print(int(QtCore.QThread.currentThreadId()), threading.current_thread().ident) ).start()

Will print out the same id, looking at that though it might not matter. If QThread.currentThread() returns a QThread object even if the thread was created with threading.Thread.start()

I've sort of been punting on this since it's hard and only sort of useful.

The environment variable to trigger whether PySide, PyQt4 or PyQt5 is loaded? see #29 I still have mixed feelings about it, but it's tests pass so it could totally be merged and shipped. The alternative is to inspect sys.modules, and then whatever is imported first is what's used.

The main ugliness of #29 is that you have to pass in a QtCore object to QThreadExecutor

[harvimt]

Also remember that there's a chat room for this project:
https://gitter.im/harvimt/quamash

[Kentzo]

You actually totally can (since they're both based on OS Threads), but only QThreads can receive signals.

Both threading.Thread and QThread are indeed wrappers around OS threads. But infrastructures they set up are different: threading.Thread cannot have Qt event loop.

In practice then it's highly impractical to not use QThreads when you're using PyQt.

One may use PyQt as UI frontend only and leverage logic of the app on other frameworks and other event loops. E.g. one of application I'm developing uses PyQt in main thread only and zeromq / http etc in other threads.

The alternative is to inspect sys.modules, and then whatever is imported first is what's used.

There is a factory method set_event_loop, that user is supposed to call for the current context. Maybe we could use something like this:

asyncio.set_event_loop(Qt4EventLoop())  # set up event loop on top of pyqt4
asyncio.set_event_loop(Qt5EventLoop())  # set up event loop on top of pyqt5

The callable will set up whatever variables for the rest of the methods.

[harvimt]

@Kentzo how much of what I'm writing are you reading?

Both threading.Thread and QThread are indeed wrappers around OS threads. But infrastructures they set up are different: threading.Thread cannot have Qt event loop.

that's what I said, though I gave the implications and not the root cause. Also I'm not entirely sure it's true. Did you see the code in my last example?

E.g. one of application I'm developing uses PyQt in main thread only and zeromq / http etc in other threads.

Pretty sure it wouldn't matter, threading.Thread might be slightly more lightweight. Regardless, quamash works fine with worker threads that aren't QThreads (for example in an executor). Also @aknuds1 was working on an implementation of aiozmq that's compatible with quamash, and Vase exists for HTTP, so you could just do everything in one thread with an event loop. (though there are advantages to putting that stuff in threads)

asyncio.set_event_loop(Qt4EventLoop())  # set up event loop on top of pyqt4
asyncio.set_event_loop(Qt5EventLoop())  # set up event loop on top of pyqt5

Clearly you didn't look at the PR, though it's quite large, so that can be forgiven. Also I use asyncio.set_event_loop in the example in the README (though I suppose it's generally better to assume ignorance even if the person you're talking to is offended)

You just do asyncio.set_event_loop(QEventLoop(app)) where app is an instance of QApplication (or QCoreApplication) in that branch, and it get's the PyQt module backwards from there.

see: https://github.com/harvimt/quamash/pull/29/files#diff-b6196c9cf4a2f8190164136b76096c05R190

That's kind of ugly, but it's not less ugly than a sys.modules hack.

The issue isn't the event loops, it's the executors: it's kind of ugly to pass in the copy of QtCore: see the Executor tests in the depinject5realz branch: https://github.com/harvimt/quamash/blob/depinject5realz/tests/test_qthreadexec.py

[harvimt]

I was totally expecting this to not work, but it totally works:

from PyQt5 import QtCore
import threading

def mythread():
    print('starting thread')
    thread = QtCore.QThread.currentThread()
    loop = QtCore.QEventLoop()
    loop.moveToThread(thread)
    QtCore.QTimer.singleShot(1000, loop.quit)
    loop.exec()
    print('thread ended')
    app.quit()

def onstart():
    threading.Thread(target=mythread).start()

def ontimer():
    print('got here')


app = QtCore.QCoreApplication([])
t = QtCore.QTimer.singleShot(0, onstart)
app.exec()

[harvimt]

also on windows!

So you can run a Qt event loop inside a threading.Thread (with a little effort)

[Kentzo]

Also @aknuds1 was working on an implementation of aiozmq that's compatible with quamash, and Vase exists for HTTP, so you could just do everything in one thread with an event loop.

What I meant is that one may want to avoid using Qt as much as possible in his / her application. If this package is designed for Qt-centric apps that's fine.

In other hand I'm not sure whether current version of asyncio supports coexistance of multiple implementation within one process.

Clearly you didn't look at the PR, though it's quite large, so that can be forgiven.
You just do asyncio.set_event_loop(QEventLoop(app)) where app is an instance of QApplication (or QCoreApplication) in that branch, and it get's the PyQt module backwards from there.

Sorry, didn't read PR that carefully :)

I was totally expecting this to not work, but it totally works

Apparently QtCore.QThread.currentThread() sets up Qt environment if needed. That's nice. Should be simple enough to implement event policy then.