The discussion the first time was focused on the packaging aspects. @pf_moore said that it needed to be separated into its own PEP, so now I’ve removed that. The preview of the updated PEP with only the runtime aspects is here. I would be interested to receive any feedback on this.
3 Likes
This looks great!
Instead of sys._emscripten_info, why wouldn’t this be in sys.implementation._emscripten? I see this is already an attribute since 3.11 but could it be moved as it’s marked unstable? This would be consistent with how implementation details are exposed on other platforms like iOS.
Further any explanation of what would be the result of platform.uname().release?
Any future consideration for wasm64?
Have the efforts on this stalled?
@RamseyK currently the information is stored on sys._emscripten_info because that was where @tiran put it. But I wouldn’t be opposed to moving it if it improves consistency.
platform.uname().release returns the version of the Emscripten compiler we compiled with. I can add this.
I am not personally interested in wasm64 but I don’t think any of this stuff makes wasm64 any worse off.
This PEP is informational and doesn’t require any approval process, so I think I can make a PR to mark it as “active”.
I don’t think that’s true. Informational PEPs need to be submitted to the SC for approval, just like any other PEP.
4 Likes
Correct as they are still PEPs.
sys.implementation._emscripten is probably more inline with other implementations.
For consistency with PEP-783, should sys.platform now return “pyemscripten” ?
Sounds great on the rest. Thank you for your work on this.
Instead of sys._emscripten_info, why wouldn’t this be in sys.implementation._emscripten? I see this is already an attribute since 3.11 but could it be moved as it’s marked unstable? This would be consistent with how implementation details are exposed on other platforms like iOS.
Other people have asked about this too. I don’t care particularly, but it does seem like a nice cleanup. Searching on github there are a decent number of people using it so I’d be cautious about moving it but it does at least have an underscore…
For consistency with PEP-783, should sys.platform now return “pyemscripten” ?
Well on linux sys.platform returns linux not manylinux. Changing this would break a lot of code that checks against “emscripten”.
Further any explanation of what would be the result of platform.uname().release?
It’s the emscripten version:
> os.uname()
posix.uname_result(sysname='Emscripten', nodename='emscripten', release='4.0.9', version='#1', machine='wasm32')
Perhaps I should add this to the PEP text.
Any future consideration for wasm64?
Personally, I’m not very interested in wasm64. It is substantially slower than wasm32 since for wasm32 each memory gets 4 gb of virtual memory and so no additional work is needed to prevent out of bounds reads/writes. This obviously won’t work with wasm64 since the wasm64 memory space is the same size as the native virtual memory space. The vast majority of web apps can make do with 4 gb of memory (if they need more they can use the file system) and there are no memory management apis so the additional virtual memory space is not usable.
On top of this supporting wasm64 requires a lot of code changes because in wasm64 all pointers are 64 bits and when they pass to JavaScript they become BigInts and adding a BigInt with a Number is a TypeError.
That said, if someone else wanted to drive wasm64 support I would be happy to help out.
1 Like
On behalf of the Steering Council: while PEP 776 is Informational and doesn’t formally require our approval, we’ve reviewed it and have no objections. The authors asked for an explicit signal from the SC given that the PEP touches CPython directly and implies Tier 3 changes to PEP 11: we’re happy to confirm we’re comfortable with the direction.
Thanks for excellent work on the PEP, @hoodmane and to @ambv for sponsoring.
Congrats! 
9 Likes