Qt Implementation Dependency Injection? about quamash HOT 7 OPEN

I am not very familiar with the quamash source with respect to that. Other projects (such as matplotlib) which have variable dependencies usually have a module which you can load beforehand and where you can set options:

import matplotlib
# selects backend
matplotlib.use("gtkagg")
# only here the dependencies are used
import matplotlib.pyplot as pyplot

In absence of that, quamash should fail to load, I think (In face of ambiguity, refuse the temptation to guess — Zen of Python): Most applications will only work with exactly one of the packages.

Ideally, the system would work in a way so that the type of the Qt application which is passed to the event loop determines which package to use. I wonder however how feasible that is, considering that the event loop itself already has a dependency on Qt (as it seems from looking into unix.py and windows.py; I have not looked closely though).

With a system as used by matplotlib, one could however provide a helper function such as make_loop_for_application which (a) inspects the Application object for the correct package to use, (b) calls use (or however that method would be called in quamash) and (c) imports the event loop, creates one and returns it.

just my thoughts :)

from quamash.

Another thought I had was looking for which modules are already loaded (in sys.modules) and pick whichever of the Qt packages was loaded. This is still guesswork, but better (and easier to implement) than the current approach I think.

from quamash.

Maybe there could be a quamash.initialize function where you specify which Qt wrapper to use (i.e., 'PyQt4', 'PyQt5' or 'PySide'). Eventually, if you pass None, Quamash could pick one automatically. For example:

quamash.initialize('PyQt5')

from quamash.

Seems people think this is a good idea? All solutions require some
inspection/metaprogramming with regards to dynamically injecting a parent
class.
On Jan 9, 2015 4:47 AM, "Arve Knudsen" [email protected] wrote:

Maybe there could be a quamash.initialize function where you specify which
Qt wrapper to use (i.e., 'PyQt4', 'PyQt5' or 'PySide'). Eventually, if you
pass None, Quamash could pick one automatically. For example:

quamash.initialize('PyQt5')

—
Reply to this email directly or view it on GitHub
#16 (comment).

from quamash.

I am not sure I like that metaprogramming part. It may introduce a lot of complexity which can be easily avoided by putting QEventLoop (and related classes) into a separate module (e.g. quamash.eventloop) and requiring the user to configure quamash before importing (from) that module.

At least for a first iteration this seems more reasonable. Extending this to a more flexible approach should be possible in the future.

from quamash.

Well I'm thinking of the things that need to happen:

A subclass of QThread is needed to make QThreadWorkers (QThreadExecutor &
QThreadWorker could totally be moved to a new module)
QObject needs to be subclassed in order for call_soon_threadsafe to work,
but this QObject subclass with custom signal need not necessarily be
QEventLoop. Finally, some sort of generic factory to create QSocketListener
instances is needed.

I think that's it.

On Fri, Jan 9, 2015 at 1:36 PM, Jonas Wielicki [email protected]
wrote:

I am not sure I like that metaprogramming part. It may introduce a lot of
complexity which can be easily avoided by putting QEventLoop (and related
classes) into a separate module (e.g. quamash.eventloop) and requiring
the user to configure quamash before importing (from) that module.

At least for a first iteration this seems more reasonable. Extending this
to a more flexible approach should be possible in the future.

—
Reply to this email directly or view it on GitHub
#16 (comment).

from quamash.

I'm working on this in https://github.com/harvimt/quamash/tree/depinject

It works just not on windows (yet)

from quamash.