-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Support for compiling functions to WASM #377
Comments
Maybe targeting WASM is a bit of a long shot, but in this line of thought, we can consider an Elm-like approach, by making PyScript more type-aware so that we can prevent errors at compile time. |
I second that! i have been reading elm but pyscript is a new groundbreaker |
As mentioned many times, a major problem with PyScript is that it looks like Python, but is really JavaScript. I wonder whether this is a problem because its not Python, or because it is worse than Python, by which I mean that JS is a language with no compile time checks so more errors at runtime. Or worse, without runtime errors (e.g. attribute access) causing the code to behave in unpredictable ways, or runtime errors in other places. I suspect that if PyScript would catch most errors at compile time, the fact that its not Python would not be that bad. Compiling to WASM is one option, but we could also just compile to JS and do type checking. The main idea is to fail early instead of later. Elm even promises to have no runtime exceptions. This somewhat relates to #367, which proposes to have classes that are instantiated either in Python or JS. We could force the JS classes to be typed. |
An example that just popped to mind is properties that are tuples. In Python these are immutable, so you need to make a copy to change them. In JS these are a list, and one can mutate the value and then set it, but Flexx will then not detect that the value has changed. I've seen this go wrong several times. |
BTW, if PyScript would target WASM instead of JS, there would be some pretty interesting implications, because WASM can (eventually) run anywhere ... For instance, one can write code to do performance critical stuff (e.g. image processing) which you could run inside the Python process. |
Beeware's Batavia approach also seems interesting https://github.com/pybee/batavia Instead of writing an interpreter or transpiler, execute the Python bytecode from JS. |
Yes, it's interesting, but really really slow :) |
Letting PyScript target WASM is not a good idea. I changed the title to reflect a more achievable goal: to support writing specific functions that run in WASM. This will likely be done by compiling typed Python to WASM. Windel is already working on something like this in the PPCI project (which, btw, may also support executing WASM in Python at some point). The purpose would be to write compute-intensive (but otherwise relatively simple) in a way that can run faster than we can in Python/JS. |
Issue moved to flexxui/pscript #6 via ZenHub |
Instead of transpiling to JavaScript, we could compile to WASM. This would make PyScript a language that is really fast, we can support ndarrays, and a safer language that fails hard when it does (unlike JS's
undefined
for nonexisting attributes).This will be really hard if you want to make it feel fully like Python. But if you make it a typed language (i.e. requiring the user to use Python's type annotations) it should be possible to statically compile it. Even then it will be a lot of work though. Probably too much, but we should at least consider it.
The text was updated successfully, but these errors were encountered: