Eric V. Smith wrote:
On 24. 01. 20 14:02, Eric V. Smith wrote: I think the concern is that with removing so many deprecated features, we're effectively telling libraries that if they want to support 3.9, they'll have stop supporting 2.7. And many library authors aren't willing to do that yet. Will they be willing to in another year? I can't say. The concern is not that they don't want to drop 2.7 support, but that is is a nontrivai task to actually do and we cannot expect them to do it within the first couple weeks of 2020. While at the same time, we want them to support 3.9 since the early development versisons in order to eb able to detect regressions early in the dev cycle. Ah. So in 3.8, they kept code that had deprecation warnings so that they could be compatible with 2.7. They'd like to now drop that code and be 3.9-only compatible, but they don't have enough time to do that because
On 1/24/2020 9:14 AM, Miro Hrončok wrote: they couldn't start that work as long as they were supporting 2.7. Do I have that right? If so, I'd be okay with postponing the removal of the deprecated code until 3.10. But I don't think we should postpone it if the driver is so that libraries can remain 2.7 compatible. That could go on forever. This postponement would be a one-time thing.
I'm also okay with a one-time delay in removals that are problematic for code trying to get off of Python 2.7 this year and might not quite cut it before 2021 hits. I'm sure some people will be caught off-guard once 3.9b1 comes out and they realize that they now have to start caring about deprecation warnings again. So I'm okay letting 3.9 be the release where we loudly declare, "deprecation warnings matter again! Keep your code warnings-free going forward as things will start being removed in 3.10".