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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4