Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Dropping Python 2 Support #62
Comments
|
Thanks for filing this Sam. My intention was that @ziransun and I will work on filing an RFC in the next few weeks for this, as we are close to having every (known) Py3 problem either fixed or at least explained.
Agreed; I have always thought of our initial support as being 3.6 and 3.8+. We would likely continue to run unittests/etc on both versions for the foreseeable future, but the WPT test suite itself would run on 3.8 in WPT CI. Re the timeline; switching to Py3-first (i.e. switch the WPT test suite runs over to Py3) in Q4 and then Py3-only in Q1 has been my hope. I didn't expect to get Py3-only as soon as Jan 1st, but I'd be happy to see it happen :). |
|
I would say that we should aim to have our CI and major vendor CI running in Py3 by 2021-01-01 but should continue to support Py2 in our CI for some time after that in case we find a reason to roll back. At a minimum I'd say a 2021-02-01 to actually drop Py2 support and start to accept Py3-only patches. |
|
Alternatively if people are comfortable with the more aggressive timeline, we could aim for out CI and vendor CI to switch before 2020-12-1. But I still have concerns that there's a lot of code not on the critical path to running tests (e.g. metadata update code) that is untested in Py 3. |
|
To consolidate everyone's suggestions so far, what about the following concrete timeline:
I also agree we should only support Python 3.6+. |
Mostly filing an issue here to at least have somewhere to write down the current Python 3 plan.
The status quo is most of our infrastructure now works on Python 3, and work is ongoing to fix the rest.
Most of us working on the infrastructure would like to minimise the amount of time we're supporting both Python 2 and Python 3, and we should probably have a discussion about both timeline for dropping Python 2 and what the minimum version of Python 3 we want to support is.
My suggestion (made privately earlier this week) was that we target 1 Jan 2021 for Python 3 only. In the immediate short term, we expect to keep the codebase in a state where Python 2 support could be trivially reintroduced, likely by simply making Python 2 supported on a "PRs welcome" basis but with no ongoing testing. In the relatively near future, maybe as soon as a month later (i.e., 1 Feb 2021), we will then start accepting PRs that will break Python 2 support significantly (e.g. replacing the comment based type annotation syntax with the Python 3 annotation syntax).
As for minimum version of Python 3, I have been assuming that we will be wanting to support Python 3.6 (as this is packaged in Ubuntu 18.04 LTS) but not Python 3.5 (note that this is dropping Debian Stretch—currently oldstable—released in 2017 and with LTS till 2022). Python 3.6 was a relatively significant release, with f-strings, stabilization of asyncio, variable annotations and more.