draft of an open pledge from Python projects to drop Python 2 support by 2020

no_more_legacy_python_pledge.md

Python 3 is the future of the Python language. Python 3 is nicer to work with than Python 2.7, making code maintenance easier. Python 3 also allows for some feature possibilities that Python 2 simply doesn't allow for. Unfortunately, many projects still support both Python 2 and 3 which is its own development burden. Supporting Python 2 can also hold a project back from supporting features only possible in Python 3.

For all of these reasons, the following projects have pledged to drop support for Python 2.7 no later than 2020, coinciding with the Python development team's timeline for dropping support for Python 2.7.

• Some project

I am almost wary of putting justification in as it can only lead to arguments. I would just stick with "we will not support past uptream".

I agree with @tacaswell - I'm wary of getting drawn into an argument by trying to justify this.

I definitely prefer Python 3, but Python 2 is still a good language and I can maintain code for it without much difficulty. The real drag is writing code to run on both - it forces us to constantly think about two different runtimes, and limits us to a subset of the language. It's quite possible - most of our projects now do it - but it's a constant small friction on development for almost every Python package.

The available stats seem to show that 2.7 is still more widely used than 3.x, so many, especially at big companies with institutional codebases, would no doubt argue that we should drop Python 3 support and go back to 2.7. In the open source world, I think we've spent enough time and energy making things work with Python 3 that they only way we're leaving the compatibility bottleneck is forwards into the brave new world of Python 3 only. But I don't see that argument winning over managers who are weighing up the cost of converting their code to Python 3.

We discussed this at the Jupyter dev meeting yesterday, and one thing that came up is how this interacts with paid support. Presumably some companies will be willing to shell out to keep stuff running on Python 2, and they're quite within their rights to do so. Possible approaches:

1. The core developers of the project (how does each project define that?) will not do any work to support Python 2, even for money.
2. We will port back to Python 2 for an appropriate price, but not release the code, charging each company to use it (this is possibly the most practical, but it runs against our open source instincts, and it may be tricky for some projects depending on their licensing and copyright assignment practices).
3. We will port back to Python 2 and release the code separately, if offered a suitable price to do the work for each release.
4. We'll stop maintaining Python 2 support for free, but we'll accept money on a recurring basis to keep supporting Python 2 in the main codebase.
5. We won't support Python 2 ourselves, but we'll provide a repo/branch where people who do want to do that can co-ordinate activity.

Obviously we can't block people from making Python 2 versions of our code as separate efforts, but we need to work out to what extent we'll support or avow such efforts.