On Fri, Nov 6, 2009 at 10:35, Nick Coghlan <ncogh...@gmail.com> wrote: > Longer term, a solution may be to extend the standard deprecation period > one release and make pending deprecation warnings required rather than > optional. That way, on the ball developers would have a full release to > quash deprecation warnings before their users encountered them by default. > > That is: > > Release X.Y: deprecated in docs, pending deprecation in code > Release X.Y+1: deprecated in code > Release X.Y+2: removed in code and docs > > (Or we could just make that the policy now and not do anything specific > in relation to the moratorium and the standard library)
This sounds like an improvement for things like Mercurial, at least. We did support 2.3-2.6 until relatively recently, and I think that's hard to get around for software that actually has to work on the user's box. This is a bit different from webapps, I suspect, where you "only" have to support the servers, which you often have more control over. But supporting 4 releases in a row has been a bit of a PITA. Luckily, we finally felt it was time to drop 2.3, so now we can make use of luxuries such as subprocess... Still, supporting 3 releases seems relatively common in the Python world (after all, parts of Zope still require 2.4, I think), and so it would be nice if the stdlib moved a little bit slower. Cheers, Dirkjan _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
