[Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

[Lennart Regebro]

On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de> wrote:
> I can confirm that the Cython project was as surprised of the PyCapsule
> change in Python 3.2 as (I guess) most other users, and I would claim that
> we are a project with one of the highest probabilities of being impacted by
> C-API changes.

And so was I. I discovered it today.

And personally, I don't mind being surprised. And I'm sorry I didn't
have time to try out the zope.* packages that support Python 3 on 3.2,
but then again the difference was supposed to be between 2.x and 3.x.
I didn't expect 3.2 to suddenly be backwards incompatible. Of the
eight packages that currently support 3.1 (in trunk), two packages do
not compile, and one gets massive test failures (which may only be
test failures, and not actual failures). That is *not* good. Perhaps
there is a easy way to map the API's with #defines, but if this is the
case, why was the change done in the first place?

But the problem here is not the surprise. If I had known about this
beforehand, that would only have helped, if I could have convinced
others that the API shouldn't have been removed!

The problem is the deprecation period!

Many projects, not only the Zope Toolkit needs to support a lot of
versions. The Zope component architecture currently supports 2.4, 2.5
and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
be dropped, but it definitely will be *years* until we can drop
support for 2.6.  But if I move the PyCObject API to the PyCapsule
API, the zope packages will **only work on Python 2.7 and 3.2**. This
is obviously not an option. If I do *not* switch, I can't support
Python 3.2. That's bad.

**We can't deprecate an API in one version and drop the API in the
next. This is not acceptable. The deprecation period must be much
longer!**

In fact, since the deprecation in the Python 2 line happened in 2.7,
the deprecation period of this API in practice was between July 3rd
2010 and February 20 2011. That is a deprecation period of somewhat
longer than seven months. Nobody obviously though 2.6 was out of
practical use by now, so why did you decide to remove one if it's
API's?


Let's make no bones about this: The PyCObject API should *not* have
been removed in 3.2. In fact, the removal should be reversed, and
3.2.1 should be released ASAP, making 3.2 a moot and unsupported
version. It can possibly be removed in 3.3, but better would be 3.4.
It must be possible to support 3-4 releases of Python with the current
release speed. We need to support python versions that are five years
old or so. In fact the deprecation period should probably be somewhat
similar to the security fix period.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64