Repository navigation
Plan for Python 2.7 Deprecation #2723
Description
(Disclaimer: This issue only relates to the Numba open source project. The Python 2.7 plans for the Anaconda Distribution will be determined by that product team, and independent of anything Numba decides to do.)
With the sunset of Python 2.7 in 2020 (though no official date set yet) only 2 years away, we should plan for how Numba will end support for Python 2.7. This issue is for discussing the plan before we put a statement in the docs.
Some factors to consider:
- NumPy's Python 2.7 plan is here
- Numba's support of Python 2.7 on Windows is already tenuous due to the fact that Python 2.7 extensions need to be built with VS2008, but LLVM can only be built with VS2015 and later. We designed llvmlite around this issue, but the solution is fragile.
- Approximately 30% of Numba conda package downloads are for Python 2.7 (trailing month, as of Feb 6).
- Numba carries quite a bit of extra code and testing burden to support both Python 2 and 3, so dropping Python 2.7 would speed up development.
- We plan to release Numba 1.0 in 2018.
Initial Proposal
- December 2018: Tag and release Numba 1.x.0. Create a Python 2.7 branch based on this release.
- Critical fixes until January 1, 2020 will be backported to the Python 2.7 branch and released as Numba 1.x.y.
- No new features will be added to the Python 2.7 branch, but we will continue to do automated testing of it with new NumPy releases.
- January 1, 2019: we will slim down the Numba master branch by removing all the Python 2.7 compatibility code and release Numba 1.(x+1).0, which will be functionally identical to Numba 1.x.0.
- January 1, 2020: The Numba developers will stop supporting the Python 2.7 branch.
Activity
godaygo commentedon Mar 30, 2018
@seibert Could you clarify in this plan - which minimum version of Python 3 will be officially supported after the split, and what minimum version will be used for internal development of
numba?seibert commentedon Mar 30, 2018
Our CI systems test and build packages for Python 2.7, 3.5 and 3.6. We dropped 3.4 testing just to keep our test burden down (our configuration matrix has ~45 combinations as it is), so if there was demand to restore it as a supported configuration, we could.
Deciding when to drop Python 3 versions is a question we can address independent of the Python 2.7 EOL.
mbargull commentedon Mar 30, 2018
(Semi-OT update regarding
See https://mail.python.org/pipermail/python-dev/2018-March/152348.html:
For general support status and EOL dates, see: https://devguide.python.org/#status-of-python-branches
Sorry for the noise, just thought that might be of interest to @godaygo and others coming by this issue.)
seibert commentedon Mar 30, 2018
Ah, good to know. I should update our docs then.
godaygo commentedon Mar 30, 2018
I will try to clarify my point. Suppose that the developers of
numbawill choose Python 3.6 fornumbainternal development after the split. It will be strange if they would not use new features introduced in this version, for example, f-strings, which will make them incompatible with any < Python 3.6. And since this split assumes that it will be necessary to port some legacy code, it would be nice to know on what minimum version to count.seibert commentedon Mar 30, 2018
I don't think we know the answer to that yet. Given the massive increase in Python 3 adoption happened during the Python 3.5 era, I suspect we will need to support 3.5 for some time. We don't intend to change the baseline at the same time as dropping Python 2.7.
Note that while Numba's implementation needs to be conservative about relying on new Python features, we can be opportunistic about supporting new Python features in the compiler when they are available. For example, Numba added support for usage of the matrix multiply operation
@(only available in Python 3.5) while still supporting Python 3.4.cdeil commentedon May 7, 2019
@seibert - Remove or update http://numba.pydata.org/numba-doc/latest/reference/python27-eol.html ?
It's not useful, just confusing, because the timeline given isn't feasible (Numba 1.0 and dropped Python 2 support should have happened by now), unless you're working on a time machine.
I think just deleting http://numba.pydata.org/numba-doc/latest/reference/python27-eol.html might be an option, it's a bit out of place in it's current location anyways (part of the "reference manual", see http://numba.pydata.org/numba-doc/latest/index.html). And you could add 2-3 more sentences concerning Python 2 removal to http://numba.pydata.org/numba-doc/latest/developer/roadmap.html - that page lists Python 2 removal before Numba 1.0, which sounds like a good idea to me. I mean, Numba 1.0 will still take time, and in the meantime supporting Python 2 becomes harder and harder, and less and less useful.
esc commentedon May 7, 2019
Related: #3917
stuartarchibald commentedon Feb 6, 2020
Python 2.7 reached EOL on January 1st, 2020 and Numba 0.47 was the last release to support Python 2.7. Closing this issue as it is Python 2.7 specific, if this problem is reproducible on Python 3 with Numba >= 0.48 then please reopen it. Many thanks!