[Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

Victor Stinner victor.stinner at gmail.com
Fri Sep 23 04:08:15 EDT 2016

2016-09-23 9:03 GMT+02:00 Chris Angelico <rosuav at gmail.com>:
> In fact, this kind of thing would be perfect for Python 4.0 - it's
> technically backward incompatible (thus justifying the 4.0 number),
> but removes only things that have been deprecated for some time, and
> have simple and direct translations.

Sorry, you missed my point.

No, I'm strongly opposed to yet another "break the world" major
release. Python 4 must not introduce deliberate backward compatible
changes for the purity of the code. The main lesson learnt from Python
3.0 is that practicality beats purity.

For me, it's fine to remove deprecated things, but only if we respect
the smooth common deprecation planning:

* pending deprecation
* deprecation
* remove

The strict minimum is a deprecation in one cycle, but it's better to
use 3 cycles (Python 3.x releases) for a smooth transition.

For Py_MEMCPY and  Py_VA_COPY, the maintenance burden is gone: these
macros are now dumb aliases. I would prefer to wait until Python 2.7
is death 7 times before removing it. But I'm proposing to keep tracks
of such macros kept for backward compatibility to remind that some
day, we should think how to remove them.

By the way, GCC has a neat "deprecated" attribute. Maybe we should
start to use it?

Currently, we don't warn technically developers of C extensions. The
best that we can do is to document deprecations C API in What's New in
Python 3.x and in the documentation of the C API... but who still read
these documentations when their C extension is stable and "just

A warning during the compilation would be a nice hint that something
is wrong and should be fixed.

Oh... I already proposed to use __attribute__((deprecated)) in november 2013 :-)


More information about the Python-Dev mailing list