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

[Victor Stinner]

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?
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

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
works"?

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 :-)
http://bugs.python.org/issue19569

Victor