gh-84461: Add sys._emscripten_info, improve docs and build (gh-91781) - #91781
gh-84461: Add sys._emscripten_info, improve docs and build (gh-91781)#91781tiran merged 2 commits into
Conversation
Sorry, something went wrong.
vstinner
left a comment
There was a problem hiding this comment.
What's the recipe using this new attribute to test if Python runs in a browser?
def is_browser():
return (not sys._emscripten_info.runtime.startswith("Node.js ")
and sys._emscripten_info.runtime != "UNKNOWN")Is that correct? What if the browser lies to set its user agent to "Node.js v1.0"?
Maybe you can rename runtime to runtime_version, and add a new runtime_name member which would be: "browser", "node" or "unknown"?
sys.implementation separates the Python implementation name from its version for example.
Sorry, something went wrong.
|
Why would you want to know that? The runtime is just for diagnostic purposes. |
Sorry, something went wrong.
I expect that some things only work on Node but not in a browser. For example, we might use it to skip some tests. If all runtime would be the exactly the same, it wouldn't be useful to add this new sys attribute :-) Python has many variables like that, used to skip tests: sys.thread_info, sys.int_info, sys.implementation, etc. |
Sorry, something went wrong.
|
I call YAGNI It is unlikely that we need to differentiate between browser and node as runtime. If we ever need to check for it, then a naive browser vs. node is probably insufficient. Instead we will have to check for optional WASM runtime features like simd128, atomics, or SAB. Let's revisit the problem when it arises. The API is deliberately marked as private and provisional for 3.11. |
Sorry, something went wrong.
If they would be the same, the list of disabled C extensions would be the same.
That's a different issue, no? |
Sorry, something went wrong.
That is a different issue. |
Sorry, something went wrong.
|
Nice enhancement! |
Sorry, something went wrong.
No description provided.