Hi all, I love Python, but as soon as I need to do something in browser I have to use ugly JavaScript !! Is there any future plans support for compiling CPython to WebAssembly using Emscripten ?
On Mon, Jun 15, 2020 at 4:46 PM <redradist@gmail.com> wrote:
There is already a project working on this: https://github.com/iodide-project/pyodide. It's in the alpha stage, but it does mostly work already.
Thanks, but I know about this implementation ... But my question is why not to apply all this patches to `CPython` to be able to compile `CPython` on the Web ? https://github.com/iodide-project/pyodide https://github.com/dgym/cpython-emscripten Patches to CPython seems pretty straightforward ...
On Monday, June 15, 2020, at 16:03 -0500, redradist@gmail.com wrote:
And my question is: are *you* prepared to develop, test, maintain, and support this for the next N years, where N is 5 or 10 or 15 or more? Or in some way to compensate those people who are? Or at least present some case as to why such an effort is its own compensation?
But my question is why not to apply all this patches to `CPython` to be able to compile `CPython` on the Web ?
Patches to CPython seems pretty straightforward ...
In order for an existing project to even be considered as a patch for CPython as an addition to the standard library, it typically requires sufficient maturity, a robust API, and thorough tests. There's also a formal PEP process that most major changes have to go through, along with taking on experts that are willing to maintain the new code and documentation for many years. That doesn't even include the discussion of whether something like that fits in the stdlib in general, or other considerations such as security (which has been an ongoing issue for WASM). So, simply because an implementation exists does not mean it should be immediately included in CPython. There are a multitude of important factors to consider, especially for something this broad. On Mon, Jun 15, 2020 at 5:04 PM <redradist@gmail.com> wrote:
Thre are already projects that build Python using Web Assembly - But as far as I know, these do not have a good interface with the document DOM. https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-sta... Maybe you'd like to take a look at Brython instead - it is a compliant Python implementatoin that transpiles Python to javascript on the client side - TL;DR: you get to write <script language="text/python>...</...>, inside your HTML - https://brython.info On Mon, 15 Jun 2020 at 17:47, <redradist@gmail.com> wrote:
The question is why not to apply all this patches to CPython to be able to compile CPython on the Web ?
conda-forge builds for ARM64 now ("miniforge"). Maybe someday conda-forge will build packages for WASM, too. The pyiodide work would probably translate well. There's a version of JupyterLab compiled to WASM w/ all of pyiodide called 'Jyve' that runs totally in the browser... Latest Chrome supports the new Native File System API "that lets websites gain write access to the native file system" https://wicg.github.io/native-file-system/ Jyve has a Brython Jupyter kernel; marked as unsafe due to there being no good way to sandbox the app JS from the notebook JS, AFAIU. WASM and MAC labels is still an open security-related question, AFAIU. PyQuery has a chained API that's familiar to jQuery users. The DOM API in Brython could probably be easily ported to CPython (and then Jython, IronPython, PyPy, RustPython). RustPython may already easily compile to WASM without any patches? https://github.com/RustPython/RustPython On Mon, Jun 15, 2020, 7:12 PM Eric V. Smith <eric@trueblade.com> wrote:
Here are the conda-forge/python-feedstock CPython patches: https://github.com/conda-forge/python-feedstock/tree/master/recipe/patches They're specified in meta.yml: https://github.com/conda-forge/python-feedstock/blob/master/recipe/meta.yaml Patches could probably be included e.g. only for a WASM arch target with jinja2 templating or just preprocessing selectors - https://docs.conda.io/projects/conda-build/en/latest/resources/define-metada... - https://docs.conda.io/projects/conda-build/en/latest/resources/define-metada... On Mon, Jun 15, 2020, 9:01 PM Wes Turner <wes.turner@gmail.com> wrote:
On Mon, Jun 15, 2020 at 4:46 PM <redradist@gmail.com> wrote:
There is already a project working on this: https://github.com/iodide-project/pyodide. It's in the alpha stage, but it does mostly work already.
Thanks, but I know about this implementation ... But my question is why not to apply all this patches to `CPython` to be able to compile `CPython` on the Web ? https://github.com/iodide-project/pyodide https://github.com/dgym/cpython-emscripten Patches to CPython seems pretty straightforward ...
On Monday, June 15, 2020, at 16:03 -0500, redradist@gmail.com wrote:
And my question is: are *you* prepared to develop, test, maintain, and support this for the next N years, where N is 5 or 10 or 15 or more? Or in some way to compensate those people who are? Or at least present some case as to why such an effort is its own compensation?
But my question is why not to apply all this patches to `CPython` to be able to compile `CPython` on the Web ?
Patches to CPython seems pretty straightforward ...
In order for an existing project to even be considered as a patch for CPython as an addition to the standard library, it typically requires sufficient maturity, a robust API, and thorough tests. There's also a formal PEP process that most major changes have to go through, along with taking on experts that are willing to maintain the new code and documentation for many years. That doesn't even include the discussion of whether something like that fits in the stdlib in general, or other considerations such as security (which has been an ongoing issue for WASM). So, simply because an implementation exists does not mean it should be immediately included in CPython. There are a multitude of important factors to consider, especially for something this broad. On Mon, Jun 15, 2020 at 5:04 PM <redradist@gmail.com> wrote:
Thre are already projects that build Python using Web Assembly - But as far as I know, these do not have a good interface with the document DOM. https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-sta... Maybe you'd like to take a look at Brython instead - it is a compliant Python implementatoin that transpiles Python to javascript on the client side - TL;DR: you get to write <script language="text/python>...</...>, inside your HTML - https://brython.info On Mon, 15 Jun 2020 at 17:47, <redradist@gmail.com> wrote:
The question is why not to apply all this patches to CPython to be able to compile CPython on the Web ?
On 6/15/2020 5:11 PM, redradist@gmail.com wrote:
The question is why not to apply all this patches to CPython to be able to compile CPython on the Web ?
Because that will cause an ongoing support burden for an unknown value. What's wrong with keeping the patches separate? Eric
conda-forge builds for ARM64 now ("miniforge"). Maybe someday conda-forge will build packages for WASM, too. The pyiodide work would probably translate well. There's a version of JupyterLab compiled to WASM w/ all of pyiodide called 'Jyve' that runs totally in the browser... Latest Chrome supports the new Native File System API "that lets websites gain write access to the native file system" https://wicg.github.io/native-file-system/ Jyve has a Brython Jupyter kernel; marked as unsafe due to there being no good way to sandbox the app JS from the notebook JS, AFAIU. WASM and MAC labels is still an open security-related question, AFAIU. PyQuery has a chained API that's familiar to jQuery users. The DOM API in Brython could probably be easily ported to CPython (and then Jython, IronPython, PyPy, RustPython). RustPython may already easily compile to WASM without any patches? https://github.com/RustPython/RustPython On Mon, Jun 15, 2020, 7:12 PM Eric V. Smith <eric@trueblade.com> wrote:
Here are the conda-forge/python-feedstock CPython patches: https://github.com/conda-forge/python-feedstock/tree/master/recipe/patches They're specified in meta.yml: https://github.com/conda-forge/python-feedstock/blob/master/recipe/meta.yaml Patches could probably be included e.g. only for a WASM arch target with jinja2 templating or just preprocessing selectors - https://docs.conda.io/projects/conda-build/en/latest/resources/define-metada... - https://docs.conda.io/projects/conda-build/en/latest/resources/define-metada... On Mon, Jun 15, 2020, 9:01 PM Wes Turner <wes.turner@gmail.com> wrote:
participants (7)
-
Dan Sommers -
Eric V. Smith -
Joao S. O. Bueno -
Kyle Stanley -
Matthew Einhorn -
redradist＠gmail.com -
Wes Turner