On Fri, 24 Jan 2020 at 08:54, Victor Stinner email@example.com wrote:
The change is that Python 2.7 is no longer supported (since 2020-01-01).
However the assertion here seems to be that some people are unprepared for this (which seems to me like it's their problem, not ours). Features getting deprecated in newer Python versions is routine. Anyone maintaining Python 2.7 compatibility should already be painfully aware that we're deprecating things in 3.x and they have to maintain compatibity code for that. We've been minimising the impact for such people as much as we can for years. When *should* we stop doing so, if not at the point where we finally declared 2.7 unsupported?
Having said that, the 5 specific changes noted seem relatively minor and deferring them an extra release doesn't seem like a massive deal. My objection is only if we try to extrapolate a general principle from those specific examples.
I'm not sure of the meaning of "buried" here. What do you mean? We propose to revert 5 changes:
It's not only about specific changes, but more a discussion about a general policy to decide if a deprecated feature should stay until 3.10, or if it's ok to remove it in 3.9.
I agree with Brett, it was hard to understand your message. And I think the problem was that you tried to discuss both the *specific* proposal to delay 5 deprecations, and the *general* principle of when we stop preserving 2.7 compatibility layers. These two are very different questions and (as I say above) don't necessarily have the same answer.
I think you should have posted *two* messages. The first very focused on the 5 deprecations, and the second, following on, saying something along the lines of "the previous message raises a broader question of how long we should carry 2.7 compatibility code before removing it - what do people think?". That would separate the general from the specific, while not flooding the list with separate threads for each deprecation (which I assume wasn't a serious suggestion on your part).