gh-84461: Add sys._emscripten_info, improve docs and build (gh-91781)

[tiran]

No description provided.

[vstinner]

What's the recipe using this new attribute to test if Python runs in a browser?

defis_browser():
return (notsys._emscripten_info.runtime.startswith("Node.js ")
andsys._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.

[tiran]

Why would you want to know that? The runtime is just for diagnostic purposes.

[vstinner]

Why would you want to know that? The runtime is just for diagnostic purposes.

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.

[tiran]

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.

[vstinner]

It is unlikely that we need to differentiate between browser and node as runtime.

If they would be the same, the list of disabled C extensions would be the same.

Instead we will have to check for optional WASM runtime features like simd128, atomics, or SAB.

That's a different issue, no?

[tiran]

If they would be the same, the list of disabled C extensions would be the same.

That is a different issue.

[vstinner]

Nice enhancement!