curses is not available on Windows

[AlexWaygood]

Refs #6734

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[msourada]

What about windows-curses? It seems to be compatible with stdlib curses and just installing it on Windows enable me to run python curses code from other platforms just fine (only linter complains about everthing about curses due to the plaform check you have implemented here)…

[Akuli]

I think removing the if statements in typeshed would be the simplest fix. I think we can't release a types-windows-curses stub package, because third-party stubs cannot override standard-library stubs as far as I know.

[AlexWaygood]

I wasn't aware of windows-curses when I made this PR. It looks like this PR also caused issues for @debonte (microsoft/pylance-release#2763), so if there's no other way of providing type hints for curses when windows-curses is installed, I'm fine with reverting this PR.

(We should add comments to the stub stating why it's not all inside a sys.platform check, if we do revert this PR, though.)

[Akuli]

third-party stubs cannot override standard-library stubs as far as I know.

I tried this and couldn't get it to work. I installed mypy and types-appdirs (any stub package would do) into a temporary venv, and then tried to rename the stub package to curses in site-packages. Mypy keeps finding the stdlib curses, so this indeed doesn't seem possible, even though https://peps.python.org/pep-0561/#type-checker-module-resolution-order places the type checker's bundled typeshed to the end of the list.

This might not have been a good idea, even if it worked. Presumably the stubs for windows-curses shouldn't be used for the regular curses, so you need something like types-windows-curses; sys_platform == "win32" in the requirements file. This would be annoying if your CI runs mypy several times on the same system, passing different platforms with the --platform argument, as you would need to install or uninstall types-windows-curses between the consecutive mypy runs.

[rmccampbell]

Hi, I just noticed this problem with windows-curses provided curses failing to autocomplete in VS Code. Is there any update on reverting this? Can I send a PR?

[AlexWaygood]

Can I send a PR?

Please do!

[rmccampbell]

Created #11241

[srittau]

I wonder whether it would be possible to have a third-party stub that "takes over" the curses namespace if types-windows-curses get installed? I am a bit uncomfortable about pretending that curses is always available on Windows.

[rmccampbell]

@Akuli implied that isn't possible at least with Mypy. Also I wonder if there is still some value for having the types available even if the module isn't supported on a platform, for development of apps that will be run in a different environment, e.g. if you use VS Code on Windows to write a script to run in WSL or a Linux VM. (Although VS Code can be attached directly to WSL and use the WSL python interpreter, sometimes that is less convenient).

[hauntsaninja]

If you're using mypy, you can use the platform option to type check as if you have some other value for sys.platform https://mypy.readthedocs.io/en/stable/config_file.html#confval-platform

[srittau]

@Akuli implied that isn't possible at least with Mypy.

It should be as per the typing specs, third-party stubs should be tried before the built-in typeshed stubs:

The following is the order in which type checkers supporting this specification SHOULD resolve modules containing type information:

1. [...]
2. [...]
3. Stub packages - these packages SHOULD supersede any installed inline package. They can be found at foopkg-stubs for package foopkg.
4. [...]
5. Typeshed (if used) - Provides the stdlib types and several third party libraries.

(Note: The language about third party libraries is outdated.)