Thanks for that!
The other question I had was how to integrate the signal/slot mechanism? Take
for example the python asyncio websockets module.
That core code looks like:
async for message in websocket:
handle(message)
or in other classes:
while True:
message = await something()
handle(something)
I'd like that to change the "handle(something)" to something more "Qt-like",
probably "yield something". The yield would then be something more akin to an
"emit" statement, where the thing being emitted would be sent to all
"connect"ed receivers.
I find the Qt way to result in far better reusable code as I can connect
multiple receivers to the same 'signal', and the code overall winds up more
loosely coupled. What I think I need to do is pass in an array of functions,
then call each one with the something:
async for message in websocket:
print(message)
for handler in self.handlers:
await handle(message) #horrible concurrency tho, should use wait() or
gather()
Furthermore, when dealing with python async, I found myself having to
create_task() for each 'emit' of each object. This may be bad python design, or
poor understanding/implementation on my part, but I think the Qt way is better.
Is anyone following what I am trying to say? Is it dumb? Am I dumb?
> Sent: Sunday, December 27, 2020 at 11:05 AM
> From: "Marian Beermann"
> To: "Jason H" , pyside@qt-project.org
> Subject: Re: [PySide] Unifying Qt and Python asyncio?
>
> There are two very different approaches to solve this problem:
>
> 1.) Run both event loops by polling one loop as a task within the other.
> This has numerous hard-to-fix problems, like poor/unpredictable latency,
> issues with unblocking tasks across the loops, logic bugs because e.g.
> UI events are processed in batches between batches of coroutine
> resumptions etc.
>
> This is what e.g. wxasync does for wxPython. Would not generally
> recommend doing this, has quite a lot of potential for headaches.
>
> 2.) Run Python coroutines using the "foreign" event loop. I believe
> asyncqt mostly implements an asyncio event loop + policy so the asyncio
> event loop *is* the Qt event loop. A very good solution. If asyncio
> itself is not needed per se, more lightweight approaches are possible (I
> wrote asynker a few years ago for this purpose).
>
> Cheers, Marian
>
___
PySide mailing list
PySide@qt-project.org
https://lists.qt-project.org/listinfo/pyside
