I’d first like to say that I have all the same challenges as outlined by mk-mxp in the PHP thread. Currently, I am the sole maintainer of the Python track + tooling, and we’re still trying to fix bugs we’ve found as we upgrade to Python 3.13. That’s apart from the work we still have on the Syllabus, exercises, and documentation. And this work is volunteer-based. It’s an ongoing challenge.
And the WASAM issues around internet connectivity, processing power needed, and browser capability are very real. As are all the challenges currently being encountered by the JavaScript track, which are likely to be challenges encountered by Python (since both are dynamic languages).
Yes - we could possibly save on server costs if we could move to using Pyodide or WASI for tooling. We’ve been considering it for the Python track. However, there are also quite a few challenges that take time to work thorough.
Here are a few (by no means all):
See this post by Brett Cannon on the state of WASI 2024. TL;DR: WASI is tier II as of 3.13, and Emscripten is no longer tier II for core CPython. So this means that if we want to teach Python 3.13+, we probably need to use WASI, and not Emscripten (which is what Pyodide uses).
We could use the Pyodide project - but because it uses Emscripten, and is also now not supported at the same level by the CPython team, there is a high chance they will continue to diverge from core Python, or at least trail CPython in features and fixes. They have already diverged in that they support certain JS APIs + calls, and there are whole core Python modules they can’t support.
The PyTest team (our test runner heavily uses PyTest) doesn’t have core support for either platform. While the folx at Anaconda have built a PyTest like package for PyScript (which also uses Emscripten & Pyodide under the covers), its not PyTest. It’s also in its first release, which means there are sure to be bugs and issues.
I do have faith that the PyTest team will get things going, and it does appear that you can get around many of the issues by careful compiling - but all of that is investigative work that will need to wait until the track is upgraded to Python 3.13.
The test runner for Python is only 1/3 of the tooling. We also have an analyzer and a representer. The Analyzer uses PyLint, and both extensively use the Python AST module. Probably even less support there than for PyTest, et. al.
I could go on an on … but the real upshot is that these things take time and careful investigation. It isn’t “simply” setting a feature flag and compiling for a different target. Right now the effort is focused on upgrading the track first (with the bugs fixed) and then investigating WASI/Emscripten afterward.
Thank you for the visibility of some of these issues. I Was not for example aware pytest, which is my preferred python testing framework did not work in these environments; or that WASI was likely to be the future of these efforts.
If progress could be made on these efforts, perhaps separately to exercism; do you think that down-the-line it’s not something you’d be against, particularly if it were to free-up more resources for your needs?
Generally speaking, if we can create a WASM test-runner that takes the same input and gives the same output as the primary one (ie, it takes files and runs the tests and converts it to JSON), we can a seperate WASM version. That’s what we’ve done with JavaScript (albeit not with WASM). The server-side one then handles CLI submissions and is the fallback of the WASM one.
The key thing is that it’s 1-1 compatible with the serverside one in terms of functionality (but not necessarily code).
It seems that (almost?) all languages have some sort of (significant) blockers right now that means WASM isn’t ready for the big-time (Exercism), but if anyone finds an tracks where it’s ready, we can start adding them slowly!
(P.S. Thanks for raising this and the respectful and collaborative way in which you’ve been engaging )
)