[Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 12:02, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> If you actually had been supporting 2.x and 3.x in parallel for the last two
> years, you would have had a deprecation period of 19 months
> and two releases. It's only if you are now migrating from 2 to 3
> that you notice the breakage for the first time.

The code in question was ported to Python 3 last year, before both 2.7 and 3.2.

I noticed the API change now because it's gone from 3.2. That's how
most API changes gets noticed: Things stop working. And that's OK.
Deprecation periods are there to help you support multiple versions at
the same time. Deprecation notices are helpful, of course, but in this
case it doesn't help. Even if I had noticed the deprecation warning in
3.1, I wouldn't have been able to do anything about that, because 2.7
had then not been released, and the new API isn't supported in 2.6. I
therefore could not have moved to the new API *because* I support both
Python 2.x and 3.x

I could have (and still can) support it by using compatibility macros
or #ifdefs, sure. But you can do that without a deprecation period.

So: without compatibility preprocessing I can no longer support 2.6.
2.7 came out seven and a half months before 3.2. Hence the deprecation
period was in practice seven and a half months.

Admittedly, in C with the preprocessing it's less of an issue, but the
C-extensions is rapidly reaching a position where there seems to be as
much compatibility macros as there is C code... :-) How long is this
going to continue. What API's are going to be needlessly removed in
Python 3.3? Could we please cool down with the backwards
incompatibility?

//Lennart