On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those that cause unforeseen trouble in real-world code can be identified in the alphas/betas, and rethought/reverted if necessary.
To be clear, my suggestion was to maintain gradual deprecations and warnings, but have a single removal event at the start of a new version major number. So there will be many years of betas and releases to haggle over. Also, I believe it is possible to separate the "mechanically fixable" breaks from larger changes in fundamentals. Few folks are willing to entertain or stomach the latter at this point in the lifecycle of Python. If one happens to occur, scheduling it for X.4 instead of X+1.0 doesn't help much, and may serve to obscure it. In some sense, distributing the breaks avoids potential/temporary bad press at the cost of easy planning. However, it feels like a very regular, easy to understand process should trump that in the long run. As a refinement to the idea above, perhaps a sub rule could be added: - No deprecations should appear in a X.9 release to give folks time to prepare. -Mike