I've thought some more about deprecations and subsequent deletions in
Python 3 (but not read the whole thread -- sorry, I've gotten sick
right after coming home from PyCon).
I think that as long as a significant number of people are still using
Python 2, it may be problematic if we start removing things (or making
other backwards-incompatible changes) from later Python 3 versions
that existed in early Python 3 versions, even if we've followed PEP 5
for the deprecation period. The problem is that --unrelated to this
issue, and for legitimate reasons that we can anticipate-- people will
likely ignore the entire Python 3 line until they're ready, which
means that they may skip the early Python 3 versions once they port to
Python 3.
For comparison, suppose you had some code that supported only Python
2.3. Now, even if you ignored Python 2.4, once you were ready for
porting to 2.5, you'd either notice the deprecations introduced in 2.4
for stuff removed in 2.5 following PEP 5, or you'd slap yourself on
the forehead for not paying attention for such a long time. But you
wouldn't complain that core development moves too fast: You know that
you are too slow.
But if you have a big app finally ported to Python 2.7 (feeling ready
Python 3) but are waiting for your last dependency to be ported to
Python 3, it's quite reasonable to ignore 3.0, 3.1, 3.2, 3.3... Until
you finally attempt to port to 3.4. And if something never got a
deprecation warning in 2.7, and was deprecated in 3.2 (say) and
removed in 3.4, you'd be in for a shock. And this is not necessarily
the kind of stuff that 2to3 does (since the feature existed in 3.0 and
3.1). In some cases 3to2 could even be wrong if we're not careful.
I don't want to be alarmist and I don't want to start another
moratorium, but I do think that we need to be aware of people coming
in "sideways" into Python 3 and missing the nice deprecations. So
let's be conservative with deprecations in the Python 3 line for now.
PS. An example of this came up offline: deprecation and eventual
removal of various frowned-upon unittest methods. But I anticipate
others.
--
--Guido van Rossum (python.org/~guido)