[Python-Dev] API deprecations in Python 3, from a Python 2 perspective (original) (raw)

Guido van Rossum guido at python.org
Thu Mar 17 16:04:05 CET 2011

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)

More information about the Python-Dev mailing list