Since asm.js came on the scene, and now Web Assembly people have created CPython patches to support building CPython with emscripten. See:

* https://github.com/PeachPy/EmCPython -- Python 2.7
* https://github.com/dgym/cpython-emscripten/tree/master/3.5.2/patches -- Python 3.5.2
* https://github.com/iodide-project/pyodide/tree/master/cpython/patches -- Python 3.7.4

To ease the compiling of CPython with emscripten it would be helpful if patches that achieved these ends for the compiling to Web Assembly with emscripten were built into the upstream source repository itself.

If web assembly were to became a supported compilation target of the upstream CPython repository this would significantly reduce the friction of allowing CPython, and the latest CPython, to become a language readily usable within the browser.

Cheers,
Simon

Do you want to provide a pull request?

you can add 
* https://github.com/pmp-p/pydk/tree/master/sources.em/Python-3.8.0b4.patchset -- Python 3.8.x 

(wasm not asm.js, clang-10+ required)

demo https://pmp-p.github.io/python-next/test.html

CPython can already run in the browser with very little patching, but major issues are :
 
 - asyncify'ing the whole wasm VM to have pre-emption over cPython's one to prevent blocking I/O slows down things *a lot* (10x)
=> (very?) bad user experience.

 - the size of vm + stdlib  ~ 30 MiB and wasm compilation time.
=> bad user experience on first load or slow connexion.

 - the lack of threading in wasm MinimumViableProduct specification (but this is the browser standard for now), that leads to rewrite bits of stdlib ( like eg asyncio module )
=> adding more maintenance burden on stdlib (!)


i tested them all and my personnal opinion is : I can see no use case that would favour "stock" cPython wasm versus a blazing fast MicroPytho (or pycopy) wasm flavour or supercharged full stack pyodide.

Hi pmp-p and Serhiy,

I'd be more than happy to attempt a pull request, but I imagine a change
such as this needs to be discussed first, trying not to "rush to make a
patch" (https://www.youtube.com/watch?v=voXVTjwnn-U&feature=youtu.be&t=2546).
Also, I doubt I will do a good job of it... but I am more than happy to try.

A note regarding "supercharged full stack pyodide", potentially without
efforts such as upstreaming into CPython and emscripten the relevant
patches, that supercharged full stack may just unfortunately stagnate. See
https://github.com/iodide-project/pyodide/issues/635#issuecomment-613408912

With respect to blocking when running Python as WASM, I have found running
the WebAssembly CPython within a webworker and signalling data back and
forth causes there to be no UI issues. It ends up being quite a neat set
up. Main down side right now however is the set up is currently going
stale, hence me believing reaching out like this is in the best interests
of Python going forward.

Cheers,
Simon

On Tue, 14 Apr 2020 at 18:58, pmp-p <report@bugs.python.org> wrote:

>
> pmp-p <pmpp.pub@gmail.com> added the comment:
>
> you can add
> *
> https://github.com/pmp-p/pydk/tree/master/sources.em/Python-3.8.0b4.patchset
> -- Python 3.8.x
>
> (wasm not asm.js, clang-10+ required)
>
> demo https://pmp-p.github.io/python-next/test.html
>
> CPython can already run in the browser with very little patching, but
> major issues are :
>
>  - asyncify'ing the whole wasm VM to have pre-emption over cPython's one
> to prevent blocking I/O slows down things *a lot* (10x)
> => (very?) bad user experience.
>
>  - the size of vm + stdlib  ~ 30 MiB and wasm compilation time.
> => bad user experience on first load or slow connexion.
>
>  - the lack of threading in wasm MinimumViableProduct specification (but
> this is the browser standard for now), that leads to rewrite bits of stdlib
> ( like eg asyncio module )
> => adding more maintenance burden on stdlib (!)
>
>
> i tested them all and my personnal opinion is : I can see no use case that
> would favour "stock" cPython wasm versus a blazing fast MicroPytho (or
> pycopy) wasm flavour or supercharged full stack pyodide.
>
> ----------
> nosy: +pmpp
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue40280>
> _______________________________________
>

I've been maintaining a Python Emscripten build for the Ren'Py (game engine) web port:
https://github.com/python-emscripten/python
https://renpy.beuc.net/

I recently tackled Python3 with a minimal/embeddable approach and checking the other ports already pointed in the discussion:
https://github.com/python-emscripten/python/tree/trunk/3.8/
(2 patches, and a short pyconfig.h fix-up)

There is also a Cython module to use the Emscripten C API.

Here's a demo at:
https://www.beuc.net/python-emscripten/demo/3/
(hello-world size: 3MB, with a few common modules: 4MB)

I can provide a pull request with a first few core changes.
Should this be done on github?

-

cross-compilation handling appears to follow an incorrect logic, in particular by querying 'dpkg' or parsing compiler output to detect include paths -- it is the (cross-)compiler's responsibility to provide the system paths, and detecting them manually causes conflicts. I had to patch setup.py. Let me know if I missed something.

Usually cross-compiling is triggered by non-matching build-type/host-type. Here cross-compilation logic is apparently triggered when exporting _PYTHON_HOST_PLATFORM=xxx manually (it's in the Makefile but not exported, and breaks normal build when exported). Is this the way it's meant to be used?