Drop support for running with Python 3.8 by cdce8p · Pull Request #17492 · python/mypy (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation23 Commits3 Checks18 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Similar to last year (#15566), start by dropping support for running mypy with Python 3.8.
Users will still be able to type check 3.8 code with --python-version 3.8 until typeshed drops the support for it.

It's a bit early as the EOL for Python 3.8 is in ~3 months. However, since the branch for 1.11.0 has been cut already, we'd only drop the support with 1.12.0 which isn't due for another 1-2 months. Additionally dropping 3.8 now will make it easier to support 3.13 with its C-API changes and also give us enough time to cleanup the remaining 3.8 code blocks and documentation references.

This comment has been minimized.

1 similar comment

This comment has been minimized.

Not sure why the Windows (>=3.9) uses the absolute file path when Linux and MacOS use the relative one. Maybe someone with a Windows system can help debug this?

Not sure why the Windows (>=3.9) uses the absolute file path when Linux and MacOS use the relative one. Maybe someone with a Windows system can help debug this?

Not sure why the difference either. The closest change in Python 3.9 related to this I could find is the second bullet point here https://docs.python.org/3/whatsnew/3.9.html#other-language-changes but it doesn't explain the difference in behavior between operating systems.

It is probably safe to just shorten the file paths in the output traceback before comparing it with the expected output. I tried this patch with the test case "mypyc/test/test_run.py::TestRun::run-loops.test::testForIterable" and it seems to fix the issue:

diff --git a/mypyc/test/test_run.py b/mypyc/test/test_run.py index 37de192a9..112074047 100644 --- a/mypyc/test/test_run.py +++ b/mypyc/test/test_run.py @@ -315,6 +315,7 @@ class TestRun(MypycDataSuite): # TODO: testDecorators1 hangs on 3.12, remove this once fixed proc.wait(timeout=30) output = proc.communicate()[0].decode("utf8")

   output = output.replace(f'  File "{os.getcwd()}{os.sep}', '  File "')
   outlines = output.splitlines()

   if testcase.config.getoption("--mypyc-showc"):

It is kind of a hack but I don't know how to fix it otherwise.

Off-topic: why not use a more recent python version like 3.12 or 3.11 for Windows tests so that we don't have to update it every year?

Not sure why the Windows (>=3.9) uses the absolute file path when Linux and MacOS use the relative one. Maybe someone with a Windows system can help debug this?

Not sure why the difference either. The closest change in Python 3.9 related to this I could find is the second bullet point here https://docs.python.org/3/whatsnew/3.9.html#other-language-changes but it doesn't explain the difference in behavior between operating systems.

Thanks! Yeah, that seems to be the culprit. Pushed our patch as it's probably the best way forward here, especially since the path deviates depending on the OS used to run the tests.

Off-topic: why not use a more recent python version like 3.12 or 3.11 for Windows tests so that we don't have to update it every year?

I don't know the exact reason but I believe the intention is to always test the "oldest" Python release with Windows. Anyway, the issue mentioned earlier persists even in newer versions. That was one of the first things I checked.

This comment has been minimized.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good. I think nice to drop support a little closer to 3.8 end of life, let's at least wait until the 1.11 release is out.

I think mypy 1.12 at least should probably still support 3.8. That way we might have a release that supports both 3.13 and 3.8. Runtime support for 3.8 is needed for projects that use mypyc and target 3.8, since it's not possible to run mypyc on a more recent Python version and target an older version.

I think mypy 1.12 at least should probably still support 3.8. That way we might have a release that supports both 3.13 and 3.8.

One option of course. Though I'm not sure that's really necessary. We didn't do that the last time. 3.7 was dropped with mypy 1.5.0 whereas only 1.6.0 added support for 3.12. I suspect many projects are looking into dropping support for 3.8 in the next few months anyway if they haven't already started doing so.

Though I'm not sure that's really necessary.

Yeah it doesn't seem necessary, but if it doesn't take any significant effort, I think it's still worth doing. 3.8 still appears to be more popular than 3.9 or 3.12, based on PyPI stats (https://pypistats.org/packages/mypy).

As of this week, Python 3.8 accounts for 10.5% of all mypy downloads and 4.8% of all downloads of mypy 1.11.*

As of this week, Python 3.8 accounts for 10.5% of all mypy downloads and 4.8% of all downloads of mypy 1.11.*

Would you recommend waiting longer to drop 3.8? I'd say it's probably still fine to do after the 1.12 release. Users interested in new type checking features are more likely to be using newer Python versions.

Additionally, it will still be possible to lint 3.8 code (for the time being) and devs can always continue using 1.12 if they are stuck on 3.8.

Sorry, I should have added an opinion, I think it's fine to drop. 4.8% isn't a lot and it will drop further.
pypistats doesn't let you see Python version breakdown for a specific mypy version, I was curious how much less than the 10.5% it would be for 1.11.*

Let's make the decision when we are closer to 1.13 release? If there have been significant regressions or issues with new functionality in 1.12 (that we haven't fixed in a point release), we can extend 3.8 support to 1.13 so that there are more options for projects that want to support both 3.8 and 3.13. Or we can decide to have one more release supporting 3.8 if it's only minimal extra effort at that point.

When this PR is closer to being merged, I suggest running pyupgrade --py39-plus <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo stretchy="false">(</mo><mi>g</mi><mi>i</mi><mi>t</mi><mi>l</mi><mi>s</mi><mo>−</mo><mi>f</mi><mi>i</mi><mi>l</mi><mi>e</mi><mi>s</mi><mi mathvariant="normal">∣</mi><mi>g</mi><mi>r</mi><mi>e</mi><mi>p</mi><mover accent="true"><mi>p</mi><mo>˙</mo></mover><mi>y</mi></mrow><annotation encoding="application/x-tex">(git ls-files | grep \.py</annotation></semantics></math>(gitls−files∣grepp˙y | grep -v setup.py) , or as a follow-up PR, and storing the commit hash in .git-blame-ignore-revs

When this PR is closer to being merged, I suggest running pyupgrade --py39-plus <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo stretchy="false">(</mo><mi>g</mi><mi>i</mi><mi>t</mi><mi>l</mi><mi>s</mi><mo>−</mo><mi>f</mi><mi>i</mi><mi>l</mi><mi>e</mi><mi>s</mi><mi mathvariant="normal">∣</mi><mi>g</mi><mi>r</mi><mi>e</mi><mi>p</mi><mover accent="true"><mi>p</mi><mo>˙</mo></mover><mi>y</mi></mrow><annotation encoding="application/x-tex">(git ls-files | grep \.py</annotation></semantics></math>(gitls−files∣grepp˙y | grep -v setup.py) , or as a follow-up PR, and storing the commit hash in .git-blame-ignore-revs

👍🏻 Yeah, I have planned to do that. It's intentionally omitted here to keep the changes to a minimum.

This comment has been minimized.

We are aiming at having another release branch created in late October/early November. If we can stick to this schedule, I think we can manage another feature release with 3.8 support, and we'll drop support afterwards.

We are aiming at having another release branch created in late October/early November. If we can stick to this schedule, I think we can manage another feature release with 3.8 support, and we'll drop support afterwards.

Sounds good 👍🏻 Just wanted to fix the merge conflicts here.

This comment has been minimized.

We can merge this after the release branch for 1.14 has been created.

Co-authored-by: Ali Hamdan ali.hamdan.dev@gmail.com

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Eyeballing it looks like 3.8 usage has halved since October. Thanks for keeping this PR fresh!