PyWorker VS module PyWorker & MPWorker #2052
WebReflection
started this conversation in
Proposals
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We currently have 3 different ways to create a "PyWorker":
@pyscript/core
module we export bothPyWorker
andMPWorker
to disambiguate between the two interpreters, read the right config and bring in the correct hooks out of the boxPyWorker
which doesn't do anything like the module exports and it requires mandatory options to specify the interpretertype
, theconfig
to use, and so on ... nothing is inferred but, most notably, there are no defaults and there is noMPWorker
counterpart ... any PyWorker via Python code needs to create references viaPyWorker(url, { "type": "pyodide" })
orPyWorker(url, { "type": "micropython" })
and I am not sure this is the best we can doOn top of that, the JS module exports need to be awaited because they need to bootstrap the whole thing so that
sync
in there can work, as well as plugins resolved and the defaultsync
attached to thexworker
reference, which is also resolved later on, once the interpreter is ready.On the other hand, the polyscript
XWorker
generic constructor accepts atype
to specify the interpreter, but in PyScript thetype
is usually eitherpy
ormpy
and we ask our users to specify atype
that is the interpreter name instead ... I find all this a bit confusing and, even if properly documented, I wonder what we could do to improve the Python side of affair.We have at least 2 options:
type
is inferred, so that<script type="py">from pyscript import PyWorker; PyWorker(url)</script>
would, by default, create a pyodideXWorker
and, as we recently introduced thepyscript.config
it's also easy to pass along that too, if the same config is desired.mpy
on main would likely bootstrap a pyodide worker, when needed, not an micropython one ... so it's practically counter-intuitive. On top of this, it doesn't reflect the JS exports with explicit names to disambiguate the used interpreter and its conifgMPWorker
to thepyscript
namespace, so thatPyWorker
by default uses pyodide, unless explicitly different, andMPWorker
will always be micropython ... we bring theconfig
in per each environment, if not specified otherwise, so we'll have a more 1:1 behavior with the exported JS counterpart, still without needing toawait
those references like we do in JSI don't know what would be the most "Pythonic" way forward, all I know is that I don't currently like neither the JS nor the Python behavior around workers, but we need to
await
on the JS side, although I really don't like theMPWorker
as a name, yet I also don't like the fact in Python we need to always specify atype
as interpreter name ... I think we could be smarter in both worlds than what we have now, but I also don't want to break the JS side of affair as that's been requested and successfully used already by various developers and breaking it would be, and feel, both sad/bad and unnecessary.What do you folks think? @ntoll @fpliger @JeffersGlass
Beta Was this translation helpful? Give feedback.
All reactions