to be added as hint in the documentation

do you have a valid use case for enabling that via PyWorker or do you think this is just a documentation matter? In latter case, we should move this to pyscript/docs repo instead, otherwise happy to discuss use case and expectations 👋

should be in pyscript/docs i guess as warning, no case anymore - moved to PyWorker for good, thanks for making me to pay attention to it

@Ridensium I have been working on getting workers to work for me.
I am currently using named workers and having success.

I would like to use Pyworker because I can initiate it entirely from within python. (not possible with named workers)
Do you have a fully working example say on pyscript.com that I could look at ?

I would like to use Pyworker because I can initiate it entirely from within python

the pyodide bootstrap is the bottleneck ... once that happens everything is at same speed as before.

if you start earlier workers manually you risk to start pyodide twice, something named workers should avoid when the env is identical.

Yes the bootstrap is an issue for me. I can use ltk.Schedule() to set off the Pyworker boot.

The main problem for me however is not the booting time. I can see why you would want to do that for Named workers.

The ONLY reason I was looking at Pyworker is to do with UI components.
E.g. I have a UI element with reactive parameters that has its own python code encapsulating it and it uses a worker. This means I can reuse that same component in many of my "apps". If this python file can start its own worker then I don't need to manually add a bunch of named workers to the index.html. Instead when I add the component by importing it - it will all just work.

No real problem to use named workers instead but I hope you can see that its easier to manage complex sets of components if they are truly independent of each other and main.py.

@Neon22 I decided to use only PyWorker too as preferring keep things pytonic as much possible. If your case is just to make UI reactive why not use micropython instead pyodide, as it's much faster in startup. You can also use asyncio if the code isnt so cpu hungry. Will check examples tomm.

@Ridensium yes mpy is my preferred but if I need to use configparser or somesuch - not available in mpy. Also some js module stuff doesn't work like base64 which I need for svg to image manipulations. I'm working on all the limitations in hopes of getting a full list for the devs.

I can see why usng Pyworker can be bad though. You don;t want to reload entire pyodide more than once