On Mon, Mar 14, 2011 at 6:30 PM, Lennart Regebro <rege...@gmail.com> wrote: > On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan...@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?
I don't know how your code works, but handling either type from C seems very straightforward to me. You can simply use #ifdef Py_COBJECT_H to see if the cobject.h header was pulled into Python.h. Similarly for Py_CAPSULE_H. All you lose is that if you do get a PyCObject, there is no way of knowing if the void pointer is of the right type. > 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!** Surely, you must be joking. Python already has a long release cycle. I'm not familiar with this feature, but suppose it is decided that there is sufficient cause to remove a feature. First, we have to wait until the next release to deprecate it. Then we have to wait yet one more release to remove it. With an 18-month release cycle, that's 27 months on average. To me, that is a very long time to wait. > 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? PyCObject was deprecated in 3.1, as well as 2.7. http://docs.python.org/release/3.1.3/c-api/cobject.html#PyCObject Reid _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
