Sebastian Rittau

This *sounds* like something we would have tried before and didn't do for one reason or another. Possibly because we also mark some of the classes as protocols, and that...

Cc @JukkaL @ilevkivskyi @rchen152 @erictraut

The need is the same as for initially adding VERSIONS: Addressing a deficiency in how type checkers can detect whether stubs are available in a certain Python version. But the...

Also just to clarify: There would be no need to immediately implement this on the type checker side and there is also no pressing need on typeshed's side to remove...

> To me, "Python version added" is clearly a standard-library thing while "supported platforms" could apply to any stub file. That's a good point. A generic way to tell type...

Ideally, both platform and Python version availability would be encoded in the stub file itself instead of an external file. But for now I think Rebecca's suggestion to use a...

According to https://stackoverflow.com/questions/51322536/python-on-unix-value-of-os-ex-notfound it exists on e.g. Solaris. We should add an `and sys.platform != "linux"` to the condition. PR welcome!

Thanks for the PR! The stubtest checks currently fail: https://github.com/python/typeshed/actions/runs/7343810747/job/19994850116?pr=11204. This is the relevant output, I think: ``` × python setup.py egg_info did not run successfully. │ exit code: 1...

I haven't thought too deeply about it, but usually our stubtest checks install the package "x" when building the stubs in the "x" directory (the package will be called "types-x")....

Could you give a full example and the type checker (plus version) you are using? I just tried some examples with mypy 1.7.1 and that seemed to work.