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.