I think there’s 2 aspects here:
- How long do PyPA projects (I’m speaking for pip here, specifically) support Python 2 in the sense of keeping Python 2 in their CI, ensuring that source code is Python 2 compatible, etc.
- How do projects deal with Python 2 only bug reports (or bugs reported on Python 2, which haven’t been reproduced on Python 3).
Item (1) is the “formal support” question. I’d personally like to stop having to deal with Python 2’s Unicode model, and get access to Python 3 features and libraries, when maintaining pip, so I’m in favour of sooner rather than later (people have had a long time to migrate off Python 2 now, so I don’t have that much sympathy for anyone who expects to still use Python 2 and yet demands to be able to use latest releases of other projects like pip and whatever libraries they are installing).
But regardless of the formal answer to (1), the problem with (2) is one of support resources and interest. If the project maintainers want to get off Python 2, they are going to be a lot less interested in fixing Python 2 problems. That’s more of a people problem - we’re entirely volunteer resourced, and regardless of any support statement, no-one has any right to require that we look at bug reports. So there’s a real possibility of saying we support 2.7, but not actually offering practical support.
I don’t know if that’s something we can formalise (I know paid software does - “we’ll keep the code working, but won’t fix newly reported bugs”) but it may be worth thinking about.
I can imagine a statement along the lines of:
Pip will continue to ensure that it runs on Python 2.7 after the 2.7 EOL date, unless bugs in Python 2.7 itself prevent this (which is unlikely). Issues reported with pip which only occur on Python 2.7 will be considered, but may not get as much attention from the developers. Equally, PRs to fix 2.7 only bugs will be considered, and may be applied (subject to normal review processes) but there may be delays dur to lack of developer resource for reviews.