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
We'll likely keep support for at least a little bit. As you linked, typeshed plans on keeping support till July 2022. I remember one of Jukka's chief concerns with 3.5 was 16.04 EOL, and that problem gets much worse with 3.6 on 18.04.
Personally, I'm a little less motivated about dropping support for 3.6 than I was for 3.5; 3.6 fixed a lot of typing ugliness and 3.5 caused a bunch of wheel building issues.
Personally I don't understand supporting deprecated Pythons, it's not like it affects the already released versions and just adds more overhead to development and adds less incentive for people using older Pythons to update.
Users in many organizations do not have an option to upgrade to a recent Python/Ubuntu. Their org has a standard version everybody should use, and this version may be quite old. They may still want to use a recent mypy to get access to bug fixes, new features, etc.
There are of course limits to how long we can support old Python versions, but I think that we should try to support them at least when this doesn't cause much friction, or while much of the Python ecosystem still supports them.
I also want to make it practical to use mypyc to compile third-party libraries on PyPI. Libraries often want to support older Python versions as well, and these users would be unhappy if they couldn't use a single mypy/mypyc version to target both new and older Python versions.
I am more on the pro dropping support sometime this year. I understand that organizations might have a standard version of python. However, those organizations should probably not have a standardized version of Python that isn't receiving security updates. Just today the support Python versions received fixes for over 15 CVEs.
Secondly, I see no reason to believe that users who are using an old version of python are using modern versions of libraries. Users that aren't updating their Python are probably also not updating their libraries, and will be fine with using older versions of the libraries that use mypyc. Those libraries should drop support for Python 3.6 when mypyc does, if they want to use mypyc, or begin to not offer mypyc-compiled wheels for more update to date versions of their library. They could also just not update mypy until they drop 3.6. I don't think many people will be interested in updating mypy for new features when most new features come from the language itself and will require Python version updates (especially without __annotations__ which isn't supported in 3.6).
Thirdly, it is hard to use metrics of downloads as a true guage of how many users are stuck on a platform. Many will not upgrade until forced to (having learned that this is the standard practice for updating software at Dropbox and no reason to believe it isn't the same practice elsewhere).
I don't think that we should necessarily drop support the moment a Python gets EOL, but I think its a good cue to begin the conversation and set a specific date/release it will happen. So I think we should treat setting the date as high priority. I think dropping support for 3.6 would be higher priority if we wanted to actually use async/await, but features like dataclasses and from __future__ import annotations could still be useful (and in the latter case potentially improve memory usage by a tad).
I also don't think we should have this conversation after every new Python deprecation, so I would propose standardizing it. I would be supportive of any time from 3 to 12 months after EOL (realistically 6 to 12 months since others wouldn't want such a fast timeframe).
mypyc/mypyc#919 would help alleviate mypyc related issues. This already works (I know because our bazel rules internally do it) but might be trickier for people with less sophisticated CI setups (in particular that rely on system python) to use.
If there's a supported way to compile modules so that they work on an earlier Python version (mypyc/mypyc#919), a policy of dropping support 6 months after EOL sounds reasonable to me. For example, we could drop support for running on 3.6 in June 2022, but we could continue to support compiling modules that run on 3.6 significantly longer. We can also continue to support mypy --python-version 3.6 for longer than 6 months after EOL (possibly indefinitely).
We can't actually accurately support mypy --python-version 3.6 indefinitely, since typeshed will not support Python 3.6 indefinitely. We currently plan to drop typeshed support for 3.6 in July.
Activity
97littleleaf11 commentedon Jan 12, 2022
I think we might keep it for another few months. We dropped python 3.5 support 10 months after the last release.
KotlinIsland commentedon Jan 12, 2022
related: python/typeshed/issues/6189
hauntsaninja commentedon Jan 12, 2022
We'll likely keep support for at least a little bit. As you linked, typeshed plans on keeping support till July 2022. I remember one of Jukka's chief concerns with 3.5 was 16.04 EOL, and that problem gets much worse with 3.6 on 18.04.
Personally, I'm a little less motivated about dropping support for 3.6 than I was for 3.5; 3.6 fixed a lot of typing ugliness and 3.5 caused a bunch of wheel building issues.
KotlinIsland commentedon Jan 12, 2022
Personally I don't understand supporting deprecated Pythons, it's not like it affects the already released versions and just adds more overhead to development and adds less incentive for people using older Pythons to update.
JukkaL commentedon Jan 12, 2022
Users in many organizations do not have an option to upgrade to a recent Python/Ubuntu. Their org has a standard version everybody should use, and this version may be quite old. They may still want to use a recent mypy to get access to bug fixes, new features, etc.
There are of course limits to how long we can support old Python versions, but I think that we should try to support them at least when this doesn't cause much friction, or while much of the Python ecosystem still supports them.
I also want to make it practical to use mypyc to compile third-party libraries on PyPI. Libraries often want to support older Python versions as well, and these users would be unhappy if they couldn't use a single mypy/mypyc version to target both new and older Python versions.
jhance commentedon Mar 17, 2022
I am more on the pro dropping support sometime this year. I understand that organizations might have a standard version of python. However, those organizations should probably not have a standardized version of Python that isn't receiving security updates. Just today the support Python versions received fixes for over 15 CVEs.
Secondly, I see no reason to believe that users who are using an old version of python are using modern versions of libraries. Users that aren't updating their Python are probably also not updating their libraries, and will be fine with using older versions of the libraries that use mypyc. Those libraries should drop support for Python 3.6 when mypyc does, if they want to use mypyc, or begin to not offer mypyc-compiled wheels for more update to date versions of their library. They could also just not update mypy until they drop 3.6. I don't think many people will be interested in updating mypy for new features when most new features come from the language itself and will require Python version updates (especially without
__annotations__which isn't supported in 3.6).Thirdly, it is hard to use metrics of downloads as a true guage of how many users are stuck on a platform. Many will not upgrade until forced to (having learned that this is the standard practice for updating software at Dropbox and no reason to believe it isn't the same practice elsewhere).
I don't think that we should necessarily drop support the moment a Python gets EOL, but I think its a good cue to begin the conversation and set a specific date/release it will happen. So I think we should treat setting the date as high priority. I think dropping support for 3.6 would be higher priority if we wanted to actually use async/await, but features like dataclasses and
from __future__ import annotationscould still be useful (and in the latter case potentially improve memory usage by a tad).I also don't think we should have this conversation after every new Python deprecation, so I would propose standardizing it. I would be supportive of any time from 3 to 12 months after EOL (realistically 6 to 12 months since others wouldn't want such a fast timeframe).
jhance commentedon Mar 17, 2022
mypyc/mypyc#919 would help alleviate mypyc related issues. This already works (I know because our bazel rules internally do it) but might be trickier for people with less sophisticated CI setups (in particular that rely on system python) to use.
JukkaL commentedon Mar 21, 2022
If there's a supported way to compile modules so that they work on an earlier Python version (mypyc/mypyc#919), a policy of dropping support 6 months after EOL sounds reasonable to me. For example, we could drop support for running on 3.6 in June 2022, but we could continue to support compiling modules that run on 3.6 significantly longer. We can also continue to support
mypy --python-version 3.6for longer than 6 months after EOL (possibly indefinitely).hauntsaninja commentedon Mar 21, 2022
We can't actually accurately support
mypy --python-version 3.6indefinitely, since typeshed will not support Python 3.6 indefinitely. We currently plan to drop typeshed support for 3.6 in July.jhance commentedon Mar 21, 2022
In that case I suppose we should drop support when typeshed does. it would not be good to have to go months without being able to update it
hauntsaninja commentedon Apr 14, 2023
What's Python 3.6?