Open srittau opened 4 months ago
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:
sys.platform <equality_operator> LS
sys.version_info[0] >= LI
sys.version_info <comparison_operator> <version_tuple>
os.name <equality_operator> LS
not
, and
, and or
Where LI
means "literal integerand
LS` means "literal string"
<version_tuple>
is one of (LI1, )
, (LI1, LI2)
, (LI1, LI2, LI3)
, (LI1, LI2, LI3, LS4)
, or (LI1, LI2, LI3, LS4, LI5)
<equality_operator>
is one of ==
or !=
<comparison_operator>
is one of <
, <=
, ==
, !=
, >
, or >=
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 os.name
or sys.platform
, but someone should confirm.
Mypy supports sys.platform but not os.name. It also supports sys.version_info[0]
(and possibly more variants; I haven't checked the mypy code). Example: https://mypy-play.net/?mypy=latest&python=3.10&gist=cbd11992b8631d8bbf8d217de99386e2.
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.
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 sys.platform
currently doesn't work with typing, i.e. users following the docs won't have code that's properly type checked.
mypy has actually always supported sys.platform.startswith
, since 2016 (in addition to ==
and !=
)
mypy doesn't support os.name
mypy supports comparisons against a potentially indexed or sliced sys.version_info
Details:
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.
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
sys.platform
currently doesn't work with typing, i.e. users following the docs won't have code that's properly type checked.
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:
if sys.version_info[0] >= 3
isn't strictly necessary (you could write if sys.version_info >= (3,)
instead), but this pattern appears in a lot of existing code, so adding support for this pattern eases adoption of typing. In PEP 729's terms, this is about making the type system usable.Here's some thoughts on the specific checks that should be allowed:
sys.platform.startswith
probably makes sense to add since it helps FreeBSD (a Tier 3 platform), is already supported by mypy, and doesn't seem difficult to add to other type checkers.platform.system()
(https://github.com/python/mypy/issues/8166) and os.name
(https://github.com/python/mypy/issues/13002) but they're not especially popular. Adding support for these would help some real-world code but I'm not sure they're important enough to add to the spec.sys.version_info
checks I'd start with the intersection of the checks supported by mypy and pyright (as listed by @erictraut and @hauntsaninja above). If there are other commonly useful checks that aren't supported by both, we can add them.There's also https://github.com/python/mypy/issues/9025 requesting that the assertion form work on any code path, not just at the top level (as a workaround, if <sys.platform check>: assert False
already works for that purpose).
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.