Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
I see that the old macro is now an alias to va_copy(). A similar change was done for Py_MEMCPY(). Would it make sense to put these old macros in a new backward_compat.h header, so maybe one day we can remove them? :-) Maybe we need at least a comment mentionning when (python version) the macro became an alias. Victor
Hello, C99 has shown slow adoption by microsoft compilers on windows. On this platform, the support of va_copy() is recent and started with Visual Studio 2013. Therefore, starting from Python 3.5, PY_VA_COPY can now be mapped directly to the native implementation of va_copy(). Hence, the proposed change might be justified. Best wishes Thierry On Wed, Sep 21, 2016 at 12:42pm, Victor Stinner < victor.stinner@gmail.com [victor.stinner@gmail.com] > wrote: I see that the old macro is now an alias to va_copy(). A similar change was done for Py_MEMCPY(). Would it make sense to put these old macros in a new backward_compat.h header, so maybe one day we can remove them? :-) Maybe we need at least a comment mentionning when (python version) the macro became an alias. Victor
On Wed, Sep 21, 2016, at 03:42, Victor Stinner wrote:
I see that the old macro is now an alias to va_copy(). A similar change was done for Py_MEMCPY(). Would it make sense to put these old macros in a new backward_compat.h header, so maybe one day we can remove them? :-)
That's fine with me, though, the maintenance burden of them is precisely one line. Just dump the compat macros in Python 4.0 I think.
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. Note: The Gtk project has similar questions on backward compatibility ;-) https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ (Migration to Gtk3 was also painful for developers, no?) Victor
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.
On Fri, Sep 23, 2016 at 4:47 PM, Benjamin Peterson <benjamin@python.org> 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.
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. ChrisA
2016-09-23 9:03 GMT+02:00 Chris Angelico <rosuav@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-Fu... 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
2016-09-23 8:47 GMT+02:00 Benjamin Peterson <benjamin@python.org>:
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.
Python 3 had the same argument with 2to3: run 2to3 once, and you are done. C99 is a new thing for Python >= 3.6, but when you want to support Python 2.7 and 3.5, you are stuck at Visual Studio 2010 which is less happy with C99 than VS 2015... Hum, I don't recall if Python 2.7 requires VS 2010 or 2008? Python 2.7 doesn't seem to be mentioned in the dev guide :-/ https://docs.python.org/devguide/setup.html#windows-compiling Victor
Hi, Python 2.7 requires VS 2008 as Microsoft provides a specific bundle https://www.microsoft.com/en-us/download/details.aspx?id=44266 Kind regards Thierry On Fri, Sep 23, 2016 at 9:05 AM +0200, "Victor Stinner" <victor.stinner@gmail.com> wrote: 2016-09-23 8:47 GMT+02:00 Benjamin Peterson :
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.
Python 3 had the same argument with 2to3: run 2to3 once, and you are done. C99 is a new thing for Python >= 3.6, but when you want to support Python 2.7 and 3.5, you are stuck at Visual Studio 2010 which is less happy with C99 than VS 2015... Hum, I don't recall if Python 2.7 requires VS 2010 or 2008? Python 2.7 doesn't seem to be mentioned in the dev guide :-/ https://docs.python.org/devguide/setup.html#windows-compiling Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tchappui%40gmail.com
On Fri, Sep 23, 2016, at 00:04, Victor Stinner wrote:
2016-09-23 8:47 GMT+02:00 Benjamin Peterson <benjamin@python.org>:
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.
Python 3 had the same argument with 2to3: run 2to3 once, and you are done. C99 is a new thing for Python >= 3.6, but when you want to support Python 2.7 and 3.5, you are stuck at Visual Studio 2010 which is less happy with C99 than VS 2015...
Python 2.7 doesn't provide Py_VA_COPY, so using it wouldn't do you much good anyway in term of Python 2/3 compatibility. This is not like 2to3 because the automatic transform is correct in all cases.
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? -- Steve
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.
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
participants (7)
-
Benjamin Peterson -
Chris Angelico -
Nick Coghlan -
Steven D'Aprano -
tchappui＠gmail.com -
Thierry Chappuis
-
Victor Stinner