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

Nick Coghlan ncoghlan at gmail.com
Sun Sep 25 10:34:03 EDT 2016

On 24 September 2016 at 18:07, Benjamin Peterson <benjamin at python.org> wrote:

On Fri, Sep 23, 2016, at 09:32, Steven D'Aprano wrote: On Thu, Sep 22, 2016 at 11:47:20PM -0700, Benjamin Peterson wrote: > > On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: > > 2016-09-22 8:02 GMT+02:00 Benjamin Peterson <benjamin at python.org>: > > > Just dump the compat macros in Python 4.0 I think. > > > > Please don't. Python 3 was so painful because we decided to make > > millions of tiny backward incompatible changes. To have a smooth > > Python 4.0 release, we should only remove things which were already > > deprecated since at least 2 cycles, and well documented as deprecated. > > I'm being flippant here because of the triviality of the change. Anyone > using PyVACOPY or PyMEMCPY can fix their code in a backwards and > forwards compatible manner in 7 seconds with a sed command.

Sorry, I haven't been following this thread in detail, so perhaps I've misunderstood. Are you assuming that anyone who is building Python from source is automatically able to diagnose C level build failures and known how to fix them using sed? I am assuming authors of CPython extensions possess those skills.

Not all projects on PyPI have active maintainers though, and on the project user end, there's a significant difference between "Can set up a C build environment well enough to let distutils build simple C extensions for a new Python release" and "Is the maintainer of the C extension".

It's often useful to think of any backwards incompatible change we make as a pruning filter on PyPI: projects that don't have active maintainers that are affected by the change won't be updated as a matter of course. The end result is then usually going to be one of:

There are some cases where a lack of active maintenance is inherently a problem (e.g. network security), so we're happy to trigger those ripple effects. In other cases, the pay-off might be in ease of maintenance for the core development team, or in ease of future learning for new Python developers.

But it doesn't matter how trivial the specific change needed is if getting it resolved and a new version published turns out to require a transfer of project ownership - the cost is in the ownership change rather than the software change itself.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list