I like this idea. Quoting the Python Zen:

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

Another complication would be to make this work seamlessly between MicroPython and PyOdide (as both orchestrator and workers).

feels like a mix of SharedWorker and PyScript donkey capabilities ... we investigated the former approach and it's mostly a no-go because requires that file to be hosted where the user wants to have these features, we cannot inject a SharedWorker on our end due Web constraints + the donkey allows you already to spwan as many workers as you want providing a local/global state to ... but there is no orchestration to synchronize those, although a leading worker could do the trick.

That being said, this feels like a lot of work for zero provided use case + if WASM doesn't have it I believe there are tons of valid reasons or limitations on the Web, hence they don't have it?

This is also not currently part of my key goals so it would need coordination with the rest of the team as this would be huge effort, imho, with tons of unknowns in the making.

/cc @ntoll

This is an interesting case, that's also a good example of why PyScript is such a fascinating project.

Clearly, multiprocessing is the "blessed" CPython way to achieve a certain end. Sadly, there's no equivalent in MicroPython. Furthermore, the web world also has a similar thing in the form of web workers that, funnily enough, I often describe as isolated sub-processes of your web page, to Pythonistas who may not yet grok the browser. All this to say that we already have the capabilities of multiprocessing via web workers. I'm with @WebReflection in that we're balancing something Pythonic (multiprocessing) with the browser (web workers) and it's already a solved problem.

Perhaps the answer is really, "in idiomatic PyScript we use the donkey or built-in worker support"..?

So:

• The Ltk uses a pub/sub approach using the polyscript XWorker. I am supposing Chris crafted this early on. Certainly long before the donkey was created.
• The donkey was (perhaps?) crafted for Josh to use to solve the specific problem (am I getting this right) of running a preloaded worker (so startup was immediate) running python code which could be inserted into the donkey, run, and report output to a ui element of some kind. (So typically showing a running code fragment to educate about python code.) It uses sync to send data back to main.
  • The donkey is setup in index.html
• The Pyworker as defined in the docs - https://docs.pyscript.net/2025.3.1/user-guide/workers/ can be initiated from index.html, or from inside the python code.
  • it does one job at a time but can do different functions and sync back for each one.
  • it can be named to make it easier to keep track of stuff.
  • is an ideal way to have mpy on main and py for the worker. (faster UI startup)
  • starting it from inside the python code makes it more useful for single file components which, in turn, make it easier to make complex UIs from premade sophisticated UI elements.

So I think I'm correct if I say:

• if you have one long running task to do every now and then
  • make a donkey or a Pyworker in index.html (so it can start without loading first)
  • call it and get the result back using sync, or have it modify a dom element directly on completion
• if you want the fastest ui startup possible using pyscript then:
  • make main an mpy and do all code that needs full cython capability using pyodide workers or donkeys.
• if you are making single file components for a complex UI then use a Pyworker created in python code, but get it started asap so it can be responsive

not sure how to best characterise the use cases for other approaches.
Maybe this would be a good thing to elucidate and put in the FAQ ?

(I continue to work on ltk 05 starter project (workers) whch is in a PR to the examples github repo.

So maybe the relevant aspect of his should be moved to docs ?as well as #2315