Skip to content
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

Python 3.10 tracking issue #10201

Closed
19 of 21 tasks
freundTech opened this issue Mar 11, 2021 · 19 comments
Closed
19 of 21 tasks

Python 3.10 tracking issue #10201

freundTech opened this issue Mar 11, 2021 · 19 comments
Labels
bug mypy got something wrong meta Issues tracking a broad area of work

Comments

@freundTech
Copy link
Contributor

freundTech commented Mar 11, 2021

Here's an issue for tracking the current state of mypy on CPython 3.10

CPython version: 3.10.0
mypy version: latest master (e6b91bd)

Dependencies:

Tests:

Features

Breaking changes

Misc

  • Build Python 3.10 wheels
  • Add Python 3.10 classifier
@freundTech freundTech added the bug mypy got something wrong label Mar 11, 2021
@hauntsaninja
Copy link
Collaborator

Here's another important part to 3.10 support: #9880

@erikkemperman
Copy link
Contributor

Not sure if this ought to be mentioned here, but test-requirements.txt pins the pytest dependency to <6.2.0, because they dropped support for Python 3.5 with their 6.2 release.

However, the tests currently fail with the Python 3.10 beta due to this bug. I've submitted a PR to backport the fix to pytest 6.1.x but it was rejected because they have a policy of not backporting to versions prior to the latest minor release.

So I guess, assuming dropping Python 3.5 support is still not an option for mypy, that the dependencies would somehow have to be split in such a way that pytest 6.1.x is used with Python 3.5 and the latest pytest can be used for Python 3.6 and up. This particular bug was fixed in pytest 6.2.4, for what it's worth.

@domdfcoding
Copy link
Contributor

Could you use PEP 508 markers in the requirements file to specify the older pytest for 3.5 and a newer version for 3.6 and later?

Something like pytest<6.2.0; python_version < "3.6"

@erikkemperman
Copy link
Contributor

erikkemperman commented May 12, 2021

Perhaps. I'm not sure what the best way to do this "split" would be, to be honest, I just wanted to signal here that something may have to be done about this.

@freundTech
Copy link
Contributor Author

freundTech commented May 12, 2021

Mypy is in the process of dropping python 3.5 support (See #9950) and CI runs on python 3.5 have already been disabled (#10345), so if python 3.5 support is dropped before python 3.10 is released the pin on pytest could just be removed entirely.

CC: @JukkaL

@cdce8p
Copy link
Collaborator

cdce8p commented May 12, 2021

Python 3.10 also adds TypeAlias (PEP 613): #9404

@erikkemperman
Copy link
Contributor

@freundTech Ah, sorry, I had not seen that. Yes, in that case it can just be set to >= 6.2.4 (to include the fix for this particular issue). Thanks!

@cdce8p
Copy link
Collaborator

cdce8p commented Aug 1, 2021

3.10 also adds KW_ONLY args to dataclasses: #10865, open PR: #10867
https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY

@domdfcoding
Copy link
Contributor

I think the _NotImplementedType issue might be sorted with Python 3.10.0rc1. I'm no longer seeing it in my own code where mypy used to flag it, and running the mypy testsuite I can't see any failures related to it.

@hauntsaninja
Copy link
Collaborator

Likely because python/typeshed#5044 made it onto mypy master

@cdce8p
Copy link
Collaborator

cdce8p commented Sep 14, 2021

Another feature: PEP 612 (Parameter Specification Variables) #8645

@JukkaL
Copy link
Collaborator

JukkaL commented Oct 8, 2021

Now that Python 3.10 is out, we should enable CI using the release version. A few tests seem to be failing, however, and may need to be fixed first. Anybody want to help with this (#11294)?

Once CI is up, we should start building 3.10 wheels in https://github.com/mypyc/mypy_mypyc-wheels.

@97littleleaf11 97littleleaf11 added the meta Issues tracking a broad area of work label Nov 12, 2021
@cpontvieux-systra
Copy link

Could a preliminary version for python 3.10 be released?

What do you think?

@Torxed
Copy link

Torxed commented Dec 27, 2021

I'd like to get this out there, and maybe this is just venting some frustration. But I find it strange that Python 3.10 was released and considered stable by the Python foundation when the associated tool chain doesn't support it. This breaks quite a few things without a clear heads up and finding information on this topic is scattered at best.

I wouldn't mind hacky CI pipelines pulling master or some feature branch, but it's not clear which branch might solve the overall issues so pulling a branch is hard. And the issues appears to have been known for some time so I'm probably repeating known facts. Or I'm very oblivious and I'm missing a simple configuration (other then downgrading) in which case apologizes.

But the roadmap on mypy-lang.org is a dead link: https://github.com/python/mypy/blob/master/ROADMAP.md.
I couldn't find my information on the FAQ either about Python 3.10. Neither does the twitter account mention it. The closest thing I could get on public sources was the blog which mentions partial support for 3.10 as if it's features that are partially supported - not runtime.

I really hope I'm overreacting and that there's a parameter I'm missing and all is well.
But this feels like more of a runtime issue than a flag missing. I'd love to help figure something out to get it running, and in my particular case it's #11851 that I'm looking in to first of all.

@andychu
Copy link

andychu commented Dec 27, 2021

I'm also eagerly awaiting MyPy support for match, but saying it breaks something doesn't make sense. It's better to have the feature in Python 3.10 than not have it, and type checking has always been outside the core.

If you need your code to be 100% statically typed, then you can't use match yet, but that's not a breakage.

@Torxed
Copy link

Torxed commented Dec 27, 2021

I'm also eagerly awaiting MyPy support for match, but saying it breaks something doesn't make sense. It's better to have the feature in Python 3.10 than not have it, and type checking has always been outside the core.

If you need your code to be 100% statically typed, then you can't use match yet, but that's not a breakage.

The breakage in my case was "simple", the pyproject.toml configuration dropped support (?) for exclude = ["path", "file.py"] syntax. For some reason it needs to be a string. While previous versions have supported it. I couldn't find any information on this breaking change, but again, simple fix. But it was frustrating nevertheless.

I welcome match too, but that was besides my original point :)

Edit: Looks like it's being brought back in #11828

@juliancoffee
Copy link

Should we check pattern matching as complete as #10191 is merged?

@freundTech
Copy link
Contributor Author

I just checked off #10191, but pattern matching also needs #12010, so I added that to the list.

@ethanhs
Copy link
Collaborator

ethanhs commented May 19, 2022

It looks like all that is left here is PEP 612 support, which can be tracked in #8645, and mypyc does not support match statements, which I think is an issue better tracked on the mypyc issue tracker. I suggest we close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong meta Issues tracking a broad area of work
Projects
None yet
Development

No branches or pull requests