[Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
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 Py_VA_COPY or Py_MEMCPY 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:
- the original author returns to active maintenance for long enough to
release an update
- an interested user contacts the original author and takes over maintenance
- affected users migrate away to a new actively maintained fork of the project
- affected users migrate away to another existing project addressing
the same need
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