You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not a bug or feature request per se, more a heads up to mypy users. It should probably be documented as part of the mypy 0.680 release.
Once #6539 lands, mypy's compatibility matrix changes shape. Until now, the matrix is essentially square: you can use any Python release >= 3.4 to run mypy, and the target version (--python-version) can be any other Python release >= 3.4 (as well as 2.7).
For releases 3.4 through 3.7, nothing changes. But if you want to target 3.8, you will have to use Python 3.8 to run mypy. The reason is that starting 3.8, mypy will be using the native ast module to parse all target Python versions except 2.7 (for which we will keep using typed_ast). We're doing this so that we won't have to keep creating new versions of typed_ast for new Python versions, which is a complex, tedious process. Instead, I've made some changes to the upstream native ast module that allow it to parse older Python 3 versions. (Though not Python 2, hence the need to keep using typed_ast for that.)
Now, currently this does not change anything, since so far there are no new features in Python 3.8 that mypy supports. But there is one new feature in 3.8 that mypy should support (assignment expressions, PEP 572), and once #6539 lands, we can immediately start writing code to support that. Without #6539, we would first have to wait for a typed_ast derived from 3.8 before we could even start coding PEP 572 support.
"But isn't this a step backwards?" I hear you ask. After all, it's very nice that mypy currently supports targeting Python versions other than the version used to run mypy. That's true, and we will still do that for older Python versions. (E.g. you can use Python 3.8 to run mypy targeting Python 2.7 through 3.7.) But if you want to target the latest Python version, you will have to use that latest version to run mypy. I think it's a relatively small price to pay -- after all, if your package claims support for Python 3.8, you probably want to use Python 3.8 to run your unit tests anyway.
Finally, note that this only constrains grammatical changes in newer Python versions. If you don't start using newer Python grammar, you can still target newer standard library versions. E.g. if you use Python 3.6 to run mypy, you can still pass --python-version 3.8, you just won't be able to use grammar that's new in Python 3.8 (IOW assignment expressions) -- but mypy will still use 3.8 to interpret checks for sys.version_info in code and stubs.
The text was updated successfully, but these errors were encountered:
I think this is fairly well known by now; and anyone who doesn't know this is unlikely to find it buried in an issue from 3 years ago. So I'm closing this issue.
This is not a bug or feature request per se, more a heads up to mypy users. It should probably be documented as part of the mypy 0.680 release.
Once #6539 lands, mypy's compatibility matrix changes shape. Until now, the matrix is essentially square: you can use any Python release >= 3.4 to run mypy, and the target version (
--python-version
) can be any other Python release >= 3.4 (as well as 2.7).For releases 3.4 through 3.7, nothing changes. But if you want to target 3.8, you will have to use Python 3.8 to run mypy. The reason is that starting 3.8, mypy will be using the native
ast
module to parse all target Python versions except 2.7 (for which we will keep usingtyped_ast
). We're doing this so that we won't have to keep creating new versions oftyped_ast
for new Python versions, which is a complex, tedious process. Instead, I've made some changes to the upstream nativeast
module that allow it to parse older Python 3 versions. (Though not Python 2, hence the need to keep usingtyped_ast
for that.)Now, currently this does not change anything, since so far there are no new features in Python 3.8 that mypy supports. But there is one new feature in 3.8 that mypy should support (assignment expressions, PEP 572), and once #6539 lands, we can immediately start writing code to support that. Without #6539, we would first have to wait for a
typed_ast
derived from 3.8 before we could even start coding PEP 572 support."But isn't this a step backwards?" I hear you ask. After all, it's very nice that mypy currently supports targeting Python versions other than the version used to run mypy. That's true, and we will still do that for older Python versions. (E.g. you can use Python 3.8 to run mypy targeting Python 2.7 through 3.7.) But if you want to target the latest Python version, you will have to use that latest version to run mypy. I think it's a relatively small price to pay -- after all, if your package claims support for Python 3.8, you probably want to use Python 3.8 to run your unit tests anyway.
Finally, note that this only constrains grammatical changes in newer Python versions. If you don't start using newer Python grammar, you can still target newer standard library versions. E.g. if you use Python 3.6 to run mypy, you can still pass
--python-version 3.8
, you just won't be able to use grammar that's new in Python 3.8 (IOW assignment expressions) -- but mypy will still use 3.8 to interpret checks forsys.version_info
in code and stubs.The text was updated successfully, but these errors were encountered: