On 24 September 2016 at 18:07, Benjamin Peterson <benjamin@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@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@gmail.com | Brisbane, Australia