-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spec: Version and platform checking underspecified #1732
Comments
I'm in favor of making the language in the typing spec more precise here, but I'd prefer not to expand the set of supported expression forms here unless there's a really compelling use case identified that cannot be handled with the currently-supported expression forms. A single example doesn't constitute a compelling use case, IMO. For the record, pyright supports:
Where
The above list was established based on real-world use cases that I've run across over the years. I don't think mypy currently supports |
Mypy supports sys.platform but not os.name. It also supports |
If I remember correctly, we have several cases in the stdlib stubs where BSD constants are not correctly guarded. While the BSD platforms are certainly not the most important ones, I think the typing system should support all supported Python platforms properly. Especially, since the recommended form to use |
mypy has actually always supported Details: |
Yeah, there seems to be quite a few instances of these platform checks where correctness is lacking due to limited support in the typing spec:
This also isn't a complete list as this was from just a very brief search for "FreeBSD" (plus the Solaris only one I just happened to find along the way). But to @erictraut's point, it's still a somewhat niche use case and I'm not sure if this warrants breaking existing tools such as Pyright. I'm curious if any actual non-Windows/Linux/Mac users have actually brought up issues related to this as that usually would imply that likely many more have encountered such issues, as well. For the most part, the current platform checks might be good enough, but there were some that basically had to be incorrect due to the limitations in the current spec: if sys.version_info >= (3, 9) and sys.platform == "linux":
# Availability: Linux >= 2.6.20, FreeBSD >= 10.1 |
I agree we should precisely specify the set of checks that type checkers are required to support. This allows library authors to be confident that the code they write will be understood consistently by type checkers. However, type checkers should be allowed to support additional version or platform checks if they choose to do so, and projects like typeshed may choose to apply more restrictive policies than the typing spec. As I see it, there are two main motivations for adding support for some pattern:
Here's some thoughts on the specific checks that should be allowed:
|
There's also python/mypy#9025 requesting that the assertion form work on any code path, not just at the top level (as a workaround, Where that feature helps is as a way of notifying typecheckers of genuinely project specific ways of checking for platform support. I'm not sure if it's feasible, but it would also be nice if platform dependent attribute fallbacks didn't fail typechecking. Currently the attribute error needs to be ignored, and then the unused ignore needs to be ignored on the platforms that do provide the attribute: try:
fs_sync = os.sync # type: ignore[attr-defined,unused-ignore]
except AttributeError:
# No os.sync on Windows
def fs_sync() -> None:
pass |
Currently, the "Version and platform checking" section of the typing spec is very barebones. It basically says:
Of course, there's a world of difference between these two forms.
The type stubs document goes into a bit more of detail, and reflects the currently implemented functionality quite well, as far as I know. It would be a good starting point.
Maybe it would also make sense to support platform checks using
startswith()
, as that is officially recommended in the Python docs, and is required to properly support some Unix variants, like FreeBSD, that include the version number in the platform string. See also python/typeshed#11876.The text was updated successfully, but these errors were encountered: