Skip to content

Compatibility matrix starting with Python 3.8 #6545

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

Closed
gvanrossum opened this issue Mar 14, 2019 · 1 comment
Closed

Compatibility matrix starting with Python 3.8 #6545

gvanrossum opened this issue Mar 14, 2019 · 1 comment

Comments

@gvanrossum
Copy link
Member

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.

@AlexWaygood
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants