[Python-Dev] API deprecations in Python 3, from a Python 2 perspective

[Terry Reedy]

On 3/17/2011 11:04 AM, Guido van Rossum wrote:
> 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.
...

> 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.

Agreed. As Raymond said, such things *should* get a warning in the next 
release of 2.7, and there will be 'next' 2.7 releases for several years 
to received such updates. As I understand it, the Pyxxx to PyCapsule 
CAPI warning was put in 2.7. If 'py3k' warnings need to be specific, I 
presume that should be possible. People should retest their stuff with 
each micro (bugfix) release anyway.

One counterpoint: everyone should ignore 3.0. And in my opinion, anyone 
who has ignored 3.1 can continue to ignore it. Which is to say, there is 
not so much 3.1 stuff frozen in place but what most everyone using 3.1 
cannot upgrade to 3.2. So jumping from 2.7 to 3.2 should not be much 
harder than to 3.1.

It might be a little harder to say this about 3.2 when 3.3 comes out.

> 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.

This came up in a tracker issue and I meant to bring it up here before 
this. Since there is no single 'Python 3', 2to3 really needs to be 
2to3.x. So I think the 2to3 that come with 3.x should be specific to 
3.x. Or 2to3 should target the latest 3.x. For instance, 2to3 could make 
the unittest name substitutions now regardless of target version since 
the now preferred names were in 3.0 already.

At the Python level, most of the recent deprecations have either been 
the delayed unittest cleanup or obscure library methods, many of which 
were undocumented and/or meant to be private. One exception is the 
change of .fromstring to .frombytes for a bytes method in one of the 
modules, a change that should have been in 3.0 but was overlooked.

-- 
Terry Jan Reedy