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

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:

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

More information about the Python-Dev mailing list