Comments (6)
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:
- https://github.com/python/mypy/blob/master/mypy/reachability.py#L218
- https://github.com/python/mypy/blob/master/mypy/reachability.py#L291
from typing.
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:
- Without the pattern, some important pattern cannot be expressed in the type system. For example, if we didn't have platform checks at all, type checkers couldn't use typeshed stubs to warn users if they're using functions that don't exist on their platform. In the terms of PEP 729, this is about making the type system useful.
- The pattern appears commonly in real-world code. For example, supporting
if sys.version_info[0] >= 3
isn't strictly necessary (you could writeif 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:
- It makes sense to look at the platforms supported by CPython, as @srittau suggested above. Those are defined in https://peps.python.org/pep-0011/. I think we should aim to make it possible to write typed code on all supported platforms up to Tier 3, though obviously the higher the tier, the higher the priority. This would imply support for various flavors of Linux, MacOS, Windows, WASM, iOS, and FreeBSD.
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.- Mypy has open issues asking for
platform.system()
(python/mypy#8166) andos.name
(python/mypy#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. - For
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.
from typing.
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
- Combinations of the above using
not
,and
, andor
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.
from typing.
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.
from typing.
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.
from typing.
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:
- https://github.com/python/typeshed/blob/main/stdlib/_socket.pyi#L180
- https://github.com/python/typeshed/blob/main/stdlib/_socket.pyi#L414
- https://github.com/python/typeshed/blob/main/stdlib/_socket.pyi#L533
- https://github.com/python/typeshed/blob/main/stdlib/_socket.pyi#L541
- https://github.com/python/typeshed/blob/main/stdlib/mmap.pyi#L103
- https://github.com/python/typeshed/blob/main/stdlib/time.pyi#L15
- https://github.com/python/typeshed/blob/main/stdlib/time.pyi#L26
- https://github.com/python/typeshed/blob/main/stdlib/os/__init__.pyi#L87
- https://github.com/python/typeshed/blob/main/stdlib/os/__init__.pyi#L710
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
from typing.
Related Issues (20)
- Conformance test: make dataclass_hash.py not rely on `typing.Hashable`? HOT 1
- Proposal: Add coerced type narrowing similar to 'cast' HOT 1
- Idenity Type HOT 2
- [spec] clarify assert_type behavior as asserting type equivalence
- [spec] better clarify the difference between a runtime type object and a static type HOT 1
- [spec] a protocol type should be assignable to object? HOT 1
- [spec] define or replace the term "concrete type" HOT 1
- [spec] conceptual foundation and glossary entries for variance
- [spec] Overload processing order HOT 2
- Clarify signification of `Annotation` HOT 2
- A generic 'frame' type
- Enable Projects? HOT 5
- (🎁) `get_type_hints` should add the class to the locals HOT 4
- Conformance tests: PEP 702 HOT 1
- [spec] Clarification: Are symbols not listed in `__all__` ever considered public? HOT 1
- [spec] Formalize excluded Protocol members HOT 2
- Introduce an Unknown type HOT 3
- [@overload]: What is the effect of the *implementation* type-signature? HOT 3
- [spec] Can staticmethod calls infer type parameters for the containing class? HOT 1
- `Counter.__init__` can't be typed safely HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typing.