PyWorker - reasons to have it and reasons to drop it #1790
Replies: 1 comment 1 reply
-
I'm not sure I understand this sentence. Can you elaborate?
So, what you are proposing here is to only supporting it in JS? Overall I feel like I'm lacking to understand the proposal and how the concrete new API would look like. Could you give a couple of examples of "what happens today" and "what it'd look like in the future", and "this would not be supported anymore because this happens"? (or something like this) |
Beta Was this translation helpful? Give feedback.
-
As it cannot be consistently available in both main and worker worlds (or at least that's what we suggest in our code, I haven't even tried) it's clear that PyWorker might cause more issues than it solves:
py
ormpy
) has tons of use cases that have been already demoed and shown here and there ... as JS on main requires zero bootstrap but having it orchestrating or reaching out foreign PLs is definitively desirableAccordingly, my proposal about PyWorker is the following:
worker
attribute is there for that very same reasonThis proposal requires changes but I think all of these are pretty straight forward and welcome for easier docs around PyWorker without compromising the JS only story on the main page for slightly more advanced users ... is there anyone against it?
Vote with 👍 this discussion to signal your approval, use 👎 otherwise to signal your disapproval, hopefully commenting what is it that you don't like (or why) and propose a way forward so we can work either ways around this topic, thank you!
Beta Was this translation helpful? Give feedback.
All reactions