PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans In summary, some niceties that would make CPython hacking a little more fun. So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)? Regards, Benjamin
On 4 June 2016 at 06:11, Benjamin Peterson <benjamin@python.org> wrote:
PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans
My most-missed C99 feature would be designated initializers. Does MSVC support them? It might allow you to do away with those giant pasted slot tables, and just write the slots you need: PyTypeObject PyUnicodeIter_Type = { PyVarObject_HEAD_INIT(&PyType_Type, 0) .tp_name = "str_iterator", .tp_basicsize = sizeof(unicodeiterobject), .tp_dealloc = unicodeiter_dealloc, .tp_getattro = PyObject_GenericGetAttr, .tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC, .tp_traverse = unicodeiter_traverse, .tp_iter = PyObject_SelfIter, .tp_iternext = unicodeiter_next, .tp_methods = unicodeiter_methods, };
So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)?
Sounds good for features that are well-supported by compilers that people use. (Are there other compilers used than just GCC and MSVC?)
Martin Panter <vadmium+py@gmail.com> wrote:
So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)?
Sounds good for features that are well-supported by compilers that people use. (Are there other compilers used than just GCC and MSVC?)
clang on OS X, but it supports pretty much everything that GCC supports as well.
On 2016-06-03 23:11, Benjamin Peterson wrote:
PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans In summary, some niceties that would make CPython hacking a little more fun.
So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)?
+1 - We never officially deprecated C89 platforms withou 64 bit integers in PEP 7. Victor's changes to pytime.h implies support for uint64_t and int64_t. C99 has mandatory long long int support. - If we also drop Solaris Studio C compiler support, we can replace header guards (e.g. #ifndef Py_PYTHON_H) with #pragma once Christian
Funny. Just two weeks ago I was helping someone who discovered a compiler that doesn't support the new relaxed variable declaration rules. I think it was on Windows. Maybe this move is a little too aggressively deprecating older Windows compilers? On Sat, Jun 4, 2016 at 10:27 AM, Christian Heimes <christian@python.org> wrote:
On 2016-06-03 23:11, Benjamin Peterson wrote:
PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans In summary, some niceties that would make CPython hacking a little more fun.
So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)?
+1
- We never officially deprecated C89 platforms withou 64 bit integers in PEP 7. Victor's changes to pytime.h implies support for uint64_t and int64_t. C99 has mandatory long long int support.
- If we also drop Solaris Studio C compiler support, we can replace header guards (e.g. #ifndef Py_PYTHON_H) with #pragma once
Christian
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Martin wrote:
On 4 June 2016 at 06:11, Benjamin Peterson <benjamin@python.org> wrote:
PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans
My most-missed C99 feature would be designated initializers. Does MSVC support them? It might allow you to do away with those giant pasted slot tables, and just write the slots you need:
PyTypeObject PyUnicodeIter_Type = { PyVarObject_HEAD_INIT(&PyType_Type, 0) .tp_name = "str_iterator", .tp_basicsize = sizeof(unicodeiterobject), .tp_dealloc = unicodeiter_dealloc, .tp_getattro = PyObject_GenericGetAttr, .tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC, .tp_traverse = unicodeiter_traverse, .tp_iter = PyObject_SelfIter, .tp_iternext = unicodeiter_next, .tp_methods = unicodeiter_methods, };
I checked and VC++ does actually support this, and it looks like they support // comments as well. I don't think it fully supports all of the C99 features - it appears They just cherry picked some stuff. The C99 standard library does appear to be fully supported with the exception of tgmath.h.
On Sat, Jun 4, 2016, at 11:32, Dino Viehland wrote:
Martin wrote:
On 4 June 2016 at 06:11, Benjamin Peterson <benjamin@python.org> wrote:
PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans
My most-missed C99 feature would be designated initializers. Does MSVC support them? It might allow you to do away with those giant pasted slot tables, and just write the slots you need:
PyTypeObject PyUnicodeIter_Type = { PyVarObject_HEAD_INIT(&PyType_Type, 0) .tp_name = "str_iterator", .tp_basicsize = sizeof(unicodeiterobject), .tp_dealloc = unicodeiter_dealloc, .tp_getattro = PyObject_GenericGetAttr, .tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC, .tp_traverse = unicodeiter_traverse, .tp_iter = PyObject_SelfIter, .tp_iternext = unicodeiter_next, .tp_methods = unicodeiter_methods, };
I checked and VC++ does actually support this, and it looks like they support // comments as well. I don't think it fully supports all of the C99 features - it appears They just cherry picked some stuff. The C99 standard library does appear to be fully supported with the exception of tgmath.h.
Are the C99 features VS++ supports documented anywhere? I couldn't find any list.
On 2016-06-04 10:47, Guido van Rossum wrote:
Funny. Just two weeks ago I was helping someone who discovered a compiler that doesn't support the new relaxed variable declaration rules. I think it was on Windows. Maybe this move is a little too aggressively deprecating older Windows compilers?
Yes, it's not support in VS 2012 and 2008 for Python 3.4 and older. New C99 features are available in VS 2013, https://blogs.msdn.microsoft.com/vcblog/2013/06/28/c1114-stl-features-fixes-... Python 3.5+ requires VS 2015 anyway. Traditionally we tried to keep backwards compatibility with older compiler versions. The new features are tempting enough to deprecate compiler versions that have been released more than five years ago. Christian
As long as we don't require extension module authors to use them -- they may have their own compatibility requirements. On Sat, Jun 4, 2016 at 11:50 AM, Christian Heimes <christian@python.org> wrote:
On 2016-06-04 10:47, Guido van Rossum wrote:
Funny. Just two weeks ago I was helping someone who discovered a compiler that doesn't support the new relaxed variable declaration rules. I think it was on Windows. Maybe this move is a little too aggressively deprecating older Windows compilers?
Yes, it's not support in VS 2012 and 2008 for Python 3.4 and older. New C99 features are available in VS 2013, https://blogs.msdn.microsoft.com/vcblog/2013/06/28/c1114-stl-features-fixes-...
Python 3.5+ requires VS 2015 anyway. Traditionally we tried to keep backwards compatibility with older compiler versions. The new features are tempting enough to deprecate compiler versions that have been released more than five years ago.
Christian
-- --Guido van Rossum (python.org/~guido)
On 2016-06-04 11:59, Guido van Rossum wrote:
As long as we don't require extension module authors to use them -- they may have their own compatibility requirements.
On Windows extension modules must be compiled with a specific version of MSVC any way. For Python 3.6 VS 2015 or newer is a hard requirement. We kept the old compiler directories around for embedders.
I'm talking about 3rd party extensions. Those may require source compatibility with older Python versions. All I'm asking for is to not require source-level use of C99 features. Of course requiring a specific compiler to work with specific CPython versions is fine. On Sat, Jun 4, 2016 at 12:05 PM, Christian Heimes <christian@python.org> wrote:
On 2016-06-04 11:59, Guido van Rossum wrote:
As long as we don't require extension module authors to use them -- they may have their own compatibility requirements.
On Windows extension modules must be compiled with a specific version of MSVC any way. For Python 3.6 VS 2015 or newer is a hard requirement.
We kept the old compiler directories around for embedders.
-- --Guido van Rossum (python.org/~guido)
On 2016-06-04 12:07, Guido van Rossum wrote:
I'm talking about 3rd party extensions. Those may require source compatibility with older Python versions. All I'm asking for is to not require source-level use of C99 features. Of course requiring a specific compiler to work with specific CPython versions is fine.
Ah, the other way around. Yes, that makes a lot of sense.
On 06/03/2016 11:11 PM, Benjamin Peterson wrote:
So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)?
+1 Clearly it'll be 3.5+ only, and clearly it'll be a specific list of features ("C89 but also permitting //-comments, variadic macros, variable declarations on any line, inline functions, and designated initializers"). But I'm looking forward to it! We already had macros for inline (e.g. Py_LOCAL_INLINE), maybe we can remove those. //arry/
Guido van Rossum <guido@python.org> wrote:
I'm talking about 3rd party extensions. Those may require source compatibility with older Python versions. All I'm asking for is to not require source-level use of C99 features.
This of course removes a lot of its usefulness. E.g. macros cannot be replaced by inline functions, as header files must still be plain C89. Sturla Molden
-----Original Message----- From: Python-Dev [mailto:python-dev-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Sturla Molden Sent: Sunday, June 5, 2016 10:29 PM To: python-dev@python.org Subject: Re: [Python-Dev] C99
Guido van Rossum <guido@python.org> wrote:
I'm talking about 3rd party extensions. Those may require source compatibility with older Python versions. All I'm asking for is to not require source-level use of C99 features.
This of course removes a lot of its usefulness. E.g. macros cannot be replaced by inline functions, as header files must still be plain C89.
Sturla Molden
I share Guido's priority there - source compatibility is more important than smoothing a few of C's rough edges. Maybe the next breaking change release this should be considered (python 4000... python 5000?)
From: Python-Dev [mailto:python-dev- bounces+vgr255=live.ca@python.org] On Behalf Of tritium- list@sdamon.com Sent: Sunday, June 05, 2016 10:35 PM To: 'Sturla Molden'; python-dev@python.org Subject: Re: [Python-Dev] C99
-----Original Message----- From: Python-Dev [mailto:python-dev-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Sturla Molden Sent: Sunday, June 5, 2016 10:29 PM To: python-dev@python.org Subject: Re: [Python-Dev] C99
Guido van Rossum <guido@python.org> wrote:
I'm talking about 3rd party extensions. Those may require source compatibility with older Python versions. All I'm asking for is to not require source-level use of C99 features.
This of course removes a lot of its usefulness. E.g. macros cannot be replaced by inline functions, as header files must still be plain C89.
Sturla Molden
I share Guido's priority there - source compatibility is more important than smoothing a few of C's rough edges.
Correct me if I'm wrong, but I think that Guido meant that the third-party extensions might require their own code (not CPython's) to be compatible with versions of CPython < 3.6, and so PEP 7 shouldn't force them to break their own backwards compatibility. Either way I'm +1 for allowing (but not enforcing) C99 syntax.
Maybe the next breaking change release this should be considered (python 4000... python 5000?)
Let's not! -Emanuel
<tritium-list@sdamon.com> wrote:
I share Guido's priority there - source compatibility is more important than smoothing a few of C's rough edges. Maybe the next breaking change release this should be considered (python 4000... python 5000?)
I was simply pointing out that Guido's priority removes a lot of the usefulness of C99 at source level. I was not saying I disagreed. If we have to keep header files clean of C99 I think this proposal just adds clutter.
I'm not sure I meant that. But if I have a 3rd party extension that compiles with 3.5 headers using C89, then it should still compile with 3.6 headers using C99. Also if I compile it for 3.5 and it only uses the ABI it should still be linkable with 3.6. On Sun, Jun 5, 2016 at 7:42 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
<tritium-list@sdamon.com> wrote:
I share Guido's priority there - source compatibility is more important than smoothing a few of C's rough edges. Maybe the next breaking change release this should be considered (python 4000... python 5000?)
I was simply pointing out that Guido's priority removes a lot of the usefulness of C99 at source level. I was not saying I disagreed. If we have to keep header files clean of C99 I think this proposal just adds clutter.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Guido van Rossum <guido@python.org> wrote:
I'm not sure I meant that. But if I have a 3rd party extension that compiles with 3.5 headers using C89, then it should still compile with 3.6 headers using C99. Also if I compile it for 3.5 and it only uses the ABI it should still be linkable with 3.6.
Ok, but if third-party developers shall be free to use a C89 compiler for their own code, we cannot have C99 in the include files. Otherwise the include files will taint the C89 purity of their source code. Personally I don't think we need to worry about compilers that don't implement C99 features like inline functions in C. How long have the Linux kernel used inline functions instead of macros? 20 years or more? Sturla
On Mon, Jun 6, 2016, at 07:23, Sturla Molden wrote:
Ok, but if third-party developers shall be free to use a C89 compiler for their own code, we cannot have C99 in the include files. Otherwise the include files will taint the C89 purity of their source code.
Personally I don't think we need to worry about compilers that don't implement C99 features like inline functions in C. How long have the Linux kernel used inline functions instead of macros? 20 years or more?
Using inline functions instead of macros doesn't have to mean anything but a performance hit on platforms that don't support them, since the inline keyword, or some other identifier, could be defined to expand to an empty token sequence on platforms that do not support it. It's much lower impact on the source code than some other C99 features.
On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
Guido van Rossum <guido@python.org> wrote:
I'm not sure I meant that. But if I have a 3rd party extension that compiles with 3.5 headers using C89, then it should still compile with 3.6 headers using C99. Also if I compile it for 3.5 and it only uses the ABI it should still be linkable with 3.6.
Ok, but if third-party developers shall be free to use a C89 compiler for their own code, we cannot have C99 in the include files. Otherwise the include files will taint the C89 purity of their source code.
Well, they should use the right compiler for the Python version they are targeting. I'm just saying that they can't afford C99 features in their own code. Not even to call C/Python APIs. I think it would be okay if e.g. Py_INCREF was an inline function in Python 3.6, as long as the way you use it remains the same. -- --Guido van Rossum (python.org/~guido)
On Mon, Jun 6, 2016 at 6:25 AM, Random832 <random832@fastmail.com> wrote:
On Mon, Jun 6, 2016, at 07:23, Sturla Molden wrote:
Ok, but if third-party developers shall be free to use a C89 compiler for their own code, we cannot have C99 in the include files. Otherwise the include files will taint the C89 purity of their source code.
Personally I don't think we need to worry about compilers that don't implement C99 features like inline functions in C. How long have the Linux kernel used inline functions instead of macros? 20 years or more?
Using inline functions instead of macros doesn't have to mean anything but a performance hit on platforms that don't support them, since the inline keyword, or some other identifier, could be defined to expand to an empty token sequence on platforms that do not support it. It's much lower impact on the source code than some other C99 features.
That could be a major performance impact. -- --Guido van Rossum (python.org/~guido)
On 06/06/2016 10:11 AM, Guido van Rossum wrote:
On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
Guido van Rossum <guido@python.org> wrote:
I'm not sure I meant that. But if I have a 3rd party extension that compiles with 3.5 headers using C89, then it should still compile with 3.6 headers using C99. Also if I compile it for 3.5 and it only uses the ABI it should still be linkable with 3.6.
Ok, but if third-party developers shall be free to use a C89 compiler for their own code, we cannot have C99 in the include files. Otherwise the include files will taint the C89 purity of their source code.
Well, they should use the right compiler for the Python version they are targeting. I'm just saying that they can't afford C99 features in their own code. Not even to call C/Python APIs. I think it would be okay if e.g. Py_INCREF was an inline function in Python 3.6, as long as the way you use it remains the same.
Right. So we could use C99 features in 3.6 .h files, as long as the same extension module, unmodified, could be compiled with 3.5 .h files with a 3.5 approved (C89) compiler, and also with a 3.6 approved (C99) compiler. The headers would be different, but so would the compilers. It's the extension module source code that must be the same in the two scenarios. We're not saying that an extension module must compile with a C89 compiler under 3.6. Eric.
Right. On Mon, Jun 6, 2016 at 7:31 AM, Eric V. Smith <eric@trueblade.com> wrote:
On 06/06/2016 10:11 AM, Guido van Rossum wrote:
On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
Guido van Rossum <guido@python.org> wrote:
I'm not sure I meant that. But if I have a 3rd party extension that compiles with 3.5 headers using C89, then it should still compile with 3.6 headers using C99. Also if I compile it for 3.5 and it only uses the ABI it should still be linkable with 3.6.
Ok, but if third-party developers shall be free to use a C89 compiler for their own code, we cannot have C99 in the include files. Otherwise the include files will taint the C89 purity of their source code.
Well, they should use the right compiler for the Python version they are targeting. I'm just saying that they can't afford C99 features in their own code. Not even to call C/Python APIs. I think it would be okay if e.g. Py_INCREF was an inline function in Python 3.6, as long as the way you use it remains the same.
Right. So we could use C99 features in 3.6 .h files, as long as the same extension module, unmodified, could be compiled with 3.5 .h files with a 3.5 approved (C89) compiler, and also with a 3.6 approved (C99) compiler.
The headers would be different, but so would the compilers. It's the extension module source code that must be the same in the two scenarios.
We're not saying that an extension module must compile with a C89 compiler under 3.6.
Eric.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On 6/6/2016 10:31 AM, Eric V. Smith wrote:
Right. So we could use C99 features in 3.6 .h files, as long as the same extension module, unmodified, could be compiled with 3.5 .h files with a 3.5 approved (C89) compiler, and also with a 3.6 approved (C99) compiler.
The headers would be different, but so would the compilers.
On Windows, the compiler would be the 2015 MS compiler in both cases. Steve Dower would know if compiler flags need to be changed to enable or stop disabling C99 features.
It's the extension module source code that must be the same in the two scenarios.
We could run the experiment ourselves by changing one or more .h files to include one or more of the C99 features we want while leaving our .c files alone in the sense of remaining C89 compatible. Compile and run the test suite. If successful, add more. We would soon find out whether any of the features we want in header files require use of C99 features in .c files that include them. With a .h standard established, we could then revise *our* .c files without imposing the same on extensions. -- Terry Jan Reedy
Hi, 2016-06-04 19:47 GMT+02:00 Guido van Rossum <guido@python.org>:
Funny. Just two weeks ago I was helping someone who discovered a compiler that doesn't support the new relaxed variable declaration rules. I think it was on Windows. Maybe this move is a little too aggressively deprecating older Windows compilers?
I understood that Python only has a tiny list of officially supported compilers. For example, MinGW is somehow explicitly not supported and I see this as a deliberate choice. I'm quite sure that all supported compilers support C99. Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago? Victor
I'll ask my colleague what his compiler setup was. On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2016-06-04 19:47 GMT+02:00 Guido van Rossum <guido@python.org>:
Funny. Just two weeks ago I was helping someone who discovered a compiler that doesn't support the new relaxed variable declaration rules. I think it was on Windows. Maybe this move is a little too aggressively deprecating older Windows compilers?
I understood that Python only has a tiny list of officially supported compilers. For example, MinGW is somehow explicitly not supported and I see this as a deliberate choice.
I'm quite sure that all supported compilers support C99.
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
Victor
-- --Guido van Rossum (python.org/~guido)
So here's the diffs that seem to indicate we were working with a compiler that wasn't full C99 (or maybe previously we were working with a compiler that had extensions?) https://github.com/dropbox/typed_ast/commit/f7497e25abc3bcceced3ca6c3be3786d... On Tue, Jun 7, 2016 at 8:18 AM, Guido van Rossum <guido@python.org> wrote:
I'll ask my colleague what his compiler setup was.
On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2016-06-04 19:47 GMT+02:00 Guido van Rossum <guido@python.org>:
Funny. Just two weeks ago I was helping someone who discovered a compiler that doesn't support the new relaxed variable declaration rules. I think it was on Windows. Maybe this move is a little too aggressively deprecating older Windows compilers?
I understood that Python only has a tiny list of officially supported compilers. For example, MinGW is somehow explicitly not supported and I see this as a deliberate choice.
I'm quite sure that all supported compilers support C99.
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
Victor
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C. Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
We should definitely keep supporting MSVC. --Guido (mobile) On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
Doesn't Cygwin build against the posix abstraction layer? Wouldn't a python built as such operate as though it was on a unix of some sort? It has been quite a while since I messed with Cygwin - if it hasn't changed, it's not really an option, especially when we have native windows builds now. It would be too much of a downgrade in experience and performance.
-----Original Message----- From: Python-Dev [mailto:python-dev-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Sturla Molden Sent: Tuesday, June 7, 2016 3:37 PM To: python-dev@python.org Subject: Re: [Python-Dev] C99
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/tritium- list%40sdamon.com
On Tue, Jun 7, 2016 at 12:37 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
No-one's proposing to use C99 indiscriminately; AFAICT the proposal was: it would make a big difference if the CPython core could start using some of C99's basic features like long long, inline functions, and mid-block declarations, and all interesting compilers support these, so let's officially switch from C89-only to C89-plus-the-bits-of-C99-that-MSVC-supports. This would be a big improvement and is just a matter of recognizing the status quo; no need to drag in anything controversial. There's no chance that CPython is going to drop MSVC support in 3.6. Intel C is hardly a viable option given that the license requires the people running the compiler to accept unbounded liability for Intel lawyer bills and imposes non-DFSG-free conditions on the compiled output. And Cygwin GCC isn't even real Windows. Maybe switching to Clang will make sense in 3.7 but that's a long ways off... -n -- Nathaniel J. Smith -- https://vorpus.org
Nathaniel Smith <njs@pobox.com> wrote:
No-one's proposing to use C99 indiscriminately;
There's no chance that CPython is going to drop MSVC support in 3.6.
Stinner was proposing that by saying "Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?" This is basically a suggestion to drop MSVC support, as I read it. That is never going to happen. Sturla
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython. In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC! Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"? Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto. Victor 2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
I am using IBM xlc aka vac - version 11. afaik it will deal with c99 features (by default I set it to behave that way because a common 'issue' is C++ style comments, when they should not be that style (fyi: not seen that in Python). IMHO: GCC is not just a compiler - it brings with it a whole set of infrastructure requirements (aka run-time environment, rte). Certainly not an issue for GNU environments, but non-gnu (e.g., posix) will/may have continual side-effects from "competing" rte.. At least that was my experience when I was using gcc rather than xlc. On 6/4/2016 9:53 AM, Martin Panter wrote:
Sounds good for features that are well-supported by compilers that people use. (Are there other compilers used than just GCC and MSVC?)
Michael Felt <michael <at> felt.demon.nl> writes:
I am using IBM xlc aka vac - version 11.
afaik it will deal with c99 features (by default I set it to behave that way because a common 'issue' is C++ style comments, when they should not be that style (fyi: not seen that in Python).
We had a couple of exotic build machines a while ago: xlc, the HPUX compiler and a couple of others all support the subset of C99 we are aiming for. In fact the support of the commercial Unix compilers for C99 is quite good -- the common error messages suggest that several of them use the same front end (Comeau?). Stefan Krah
Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)? On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin
GCC
are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
_______________________________________________ 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/brett%40python.org
That sounds fine to me, but we need to list specific compiler versions. On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
_______________________________________________ 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/brett%40python.org
-- --Guido van Rossum (python.org/~guido)
On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanrossum@gmail.com> wrote:
That sounds fine to me, but we need to list specific compiler versions.
Would you want this to be static (e.g. MSVC 2016 until we choose to update to support C11), or would you want it to vary based on what's available when the current/last Python is/was released (e.g. whatever version of MSVC Steve uses to build the binaries for 3.5 or 3.6 in our current case)?
On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the
C
standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
_______________________________________________ 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/brett%40python.org
-- --Guido van Rossum (python.org/~guido)
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens. If you have to ask Steve what version he used, ask! On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon <brett@python.org> wrote:
On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanrossum@gmail.com> wrote:
That sounds fine to me, but we need to list specific compiler versions.
Would you want this to be static (e.g. MSVC 2016 until we choose to update to support C11), or would you want it to vary based on what's available when the current/last Python is/was released (e.g. whatever version of MSVC Steve uses to build the binaries for 3.5 or 3.6 in our current case)?
On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
> Is it worth to support a compiler that in 2016 doesn't support the > C > standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
_______________________________________________ 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/brett%40python.org
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum@gmail.com> wrote:
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens.
OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are the latest releases (unless I'm missing a compiler we all feel like we should officially support).
If you have to ask Steve what version he used, ask!
I know of what compiler has been used by Steve, I was just trying to give a very loose example of how it could be phrased if we wanted a shifting window of support based on what was available at the time of release for Python instead of the "what was available Aug 2016" static specification that you said you wanted.
On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon <brett@python.org> wrote:
On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanrossum@gmail.com>
That sounds fine to me, but we need to list specific compiler versions.
Would you want this to be static (e.g. MSVC 2016 until we choose to update to support C11), or would you want it to vary based on what's available when the current/last Python is/was released (e.g. whatever version of MSVC Steve uses to build the binaries for 3.5 or 3.6 in our current case)?
On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
Where did we finally land on this discussion? Do we want to update
PEP 7
to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support
a
feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote: > > Victor Stinner <victor.stinner@gmail.com> wrote: > > > Is it worth to support a compiler that in 2016 doesn't support
wrote: the
> > C > > standard released in 1999, 17 years ago? > > MSVC only supports C99 when its needed for C++11 or some MS > extension > to > C. > > Is it worth supporting MSVC? If not, we have Intel C, Clang and > Cygwin > GCC > are the viable options we have on Windows (and perhaps Embarcadero, > but > I > haven't used C++ builder for a very long time). Even MinGW does not > fully > support C99, because it depends on Microsoft's CRT. If we think MSVC > and > MinGW are worth supporting, we cannot just use C99 indiscriminantly. > > _______________________________________________ > 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
_______________________________________________ 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/brett%40python.org
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
I think if we want to revisit this in the future it should be an explicit change. On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon <brett@python.org> wrote:
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum@gmail.com> wrote:
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens.
OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are the latest releases (unless I'm missing a compiler we all feel like we should officially support).
If you have to ask Steve what version he used, ask!
I know of what compiler has been used by Steve, I was just trying to give a very loose example of how it could be phrased if we wanted a shifting window of support based on what was available at the time of release for Python instead of the "what was available Aug 2016" static specification that you said you wanted.
On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon <brett@python.org> wrote:
On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanrossum@gmail.com> wrote:
That sounds fine to me, but we need to list specific compiler versions.
Would you want this to be static (e.g. MSVC 2016 until we choose to update to support C11), or would you want it to vary based on what's available when the current/last Python is/was released (e.g. whatever version of MSVC Steve uses to build the binaries for 3.5 or 3.6 in our current case)?
On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>: > We should definitely keep supporting MSVC. > > --Guido (mobile) > > On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> > wrote: >> >> Victor Stinner <victor.stinner@gmail.com> wrote: >> >> > Is it worth to support a compiler that in 2016 doesn't support >> > the >> > C >> > standard released in 1999, 17 years ago? >> >> MSVC only supports C99 when its needed for C++11 or some MS >> extension >> to >> C. >> >> Is it worth supporting MSVC? If not, we have Intel C, Clang and >> Cygwin >> GCC >> are the viable options we have on Windows (and perhaps >> Embarcadero, >> but >> I >> haven't used C++ builder for a very long time). Even MinGW does >> not >> fully >> support C99, because it depends on Microsoft's CRT. If we think >> MSVC >> and >> MinGW are worth supporting, we cannot just use C99 >> indiscriminantly. >> >> _______________________________________________ >> 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/guido%40python.org > > > _______________________________________________ > 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/victor.stinner%40gmail.co... > _______________________________________________ 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/brett%40python.org
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
FYI, it's MSVC 14.0 (which is included in VS 2015). Personally I'd like to see it restricted to the common subset of C99 and some version of C++ (which is obviously mostly C and includes no C++), because I know there are a few things in C99 only that are very obscure because they aren't also in C++. I'd settle for saying that all header files must be C++ compatible so that embedders and extenders have the option of C or C++, even if we allow the obscure parts of C99 inside our code. Cheers, Steve Top-posted from my Windows Phone -----Original Message----- From: "Brett Cannon" <brett@python.org> Sent: 8/5/2016 15:44 To: "Guido van Rossum" <gvanrossum@gmail.com> Cc: "Python-Dev" <python-dev@python.org>; "Sturla Molden" <sturla.molden@gmail.com> Subject: Re: [Python-Dev] C99 On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanrossum@gmail.com> wrote: That sounds fine to me, but we need to list specific compiler versions. Would you want this to be static (e.g. MSVC 2016 until we choose to update to support C11), or would you want it to vary based on what's available when the current/last Python is/was released (e.g. whatever version of MSVC Steve uses to build the binaries for 3.5 or 3.6 in our current case)? On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com> wrote:
I guess that as usual, we should use the "common denominator" of all compilers supported by CPython. For example, if MSVC doesn't support a feature, we should not use it in CPython.
In practice, it's easy to check if a feature is supported or not: we have buildbots building Python at each commit. It was very common to get a compilation error only on MSVC when a variable was defined in the middle of a function. We are now using -Werror=declaration-after-statement with GCC because of MSVC!
Maybe GCC has an option to ask for the subset of the C99 standard compatible with MSVC? Something like "-std=c99 -pedantic"?
Note: I tried -pedantic, GCC emits a lot of warnings on code which looks valid and/or is protected with #ifdef for features specific to GCC like computed goto.
Victor
2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com> wrote:
Victor Stinner <victor.stinner@gmail.com> wrote:
Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?
MSVC only supports C99 when its needed for C++11 or some MS extension to C.
Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly.
_______________________________________________ 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/guido%40python.org
_______________________________________________ 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/victor.stinner%40gmail.co...
_______________________________________________ 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/brett%40python.org
-- --Guido van Rossum (python.org/~guido)
On 6 August 2016 at 12:15, Steve Dower <steve.dower@python.org> wrote:
FYI, it's MSVC 14.0 (which is included in VS 2015).
Personally I'd like to see it restricted to the common subset of C99 and some version of C++ (which is obviously mostly C and includes no C++), because I know there are a few things in C99 only that are very obscure because they aren't also in C++.
As a pragmatic requirement, what if we went with: - must compile with the Python 3.5 Windows compiler (so MSVC 14.0) - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513) The reason I like the pragmatic definition is that it's one we can readily automate by ensuring these 3 configurations are always present in the stable buildbot fleet, while the formal standards based version is technically more precise, but not in a way we can easily test. It also gives us an objective criterion for when we change the definitions: when the baseline compiler version for the respective platform builds change, and Python 3.x versions using the older definition are no longer supported by python-dev. Phrasing the policy that way would mean moving future iterations of the manylinux spec out of distutils-sig only territory into one which needs to be reviewed by both distutils-sig and python-dev (since it would now also modify CPython's compiler compatibility requirements in PEP 7), but I think that's a reasonable position to adopt, and unlikely to cause any major problems (manylinux is a *trailing* edge definition that is only likely to get updated as the oldest enterprise Linux definitions drop out of commercial support) The other question we need to consider is the possible impact on PEP 11: what happens to support for alternate compilers and platforms that *have* a buildbot, but may not support particular C99 features? Should there be a 4th clause that says "- must compile and run on all stable buildbots"? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Aug 5, 2016, at 23:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
As a pragmatic requirement, what if we went with:
- must compile with the Python 3.5 Windows compiler (so MSVC 14.0) - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
The reason I like the pragmatic definition is that it's one we can readily automate by ensuring these 3 configurations are always present in the stable buildbot fleet, while the formal standards based version is technically more precise, but not in a way we can easily test.
It also gives us an objective criterion for when we change the definitions: when the baseline compiler version for the respective platform builds change, and Python 3.x versions using the older definition are no longer supported by python-dev.
Phrasing the policy that way would mean moving future iterations of the manylinux spec out of distutils-sig only territory into one which needs to be reviewed by both distutils-sig and python-dev (since it would now also modify CPython's compiler compatibility requirements in PEP 7), but I think that's a reasonable position to adopt, and unlikely to cause any major problems (manylinux is a *trailing* edge definition that is only likely to get updated as the oldest enterprise Linux definitions drop out of commercial support)
The other question we need to consider is the possible impact on PEP 11: what happens to support for alternate compilers and platforms that *have* a buildbot, but may not support particular C99 features? Should there be a 4th clause that says "- must compile and run on all stable buildbots"?
[Nick's reply above arrived just as I was getting ready to send my own response below which covers some of the same territory.] On Aug 5, 2016, at 18:37, Guido van Rossum <gvanrossum@gmail.com> wrote:
I think if we want to revisit this in the future it should be an explicit change. On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon <brett@python.org> wrote:
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens. OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum@gmail.com> wrote: the latest releases (unless I'm missing a compiler we all feel like we should officially support).
While in principle allowing C99 features to be used in cpython is a *good* thing, I'm sure that I don't fully understand all of the implications of adopting this policy for 3.6. I think we need to be sure we don't inadvertently drop support for some platforms and/or older releases of some platforms. The key word is "inadvertently". Not all of those compiler versions above are supported everywhere we currently run. If that's what we want to do, that's fine but we should be explicit about that. Two sets of concerns that come to mind are our buildbots and support for older OS X releases. If I gathered the data correctly, for the default branch (upcoming 3.6 release), we currently have 31 buildbots: 19 classified as "stable" and 12 as "unstable". Of the stable buildbots, here is the count, version, and platform architecture of compilers in use: 2 x MSVC 14.0 2015 64 bit (AMD64) 1 x MSVC 14.0 2015 32 bit (AMD64) 1 x Clang 3.8.0 (AMD64) 1 x Clang 3.4.1 (AMD64) 1 x GCC 5.3.1 (s390x) 2 x GCC 4.9.3 (x86) 2 x GCC 4.9.2 (AMD64) 1 x GCC 4.9.2 (PPC64LE) 2 x GCC 4.8.5 (s390x) 1 x GCC 4.8.4 (x86) 1 x GCC 4.8.3 (PPC64) 1 x GCC 4.3.3 (AMD64) 2 x GCC 4.2.1 (AMD64) 1 x GCC 4.0.1 (x86) I know very little about the details of C99 support in those compilers but I gather from this link (https://gcc.gnu.org/c99status.html) that GCC 4.5 is potentially the earliest level that properly supports C99. Note that we have a number of buildbots running version of GCC older than 4.5 (including all of our OS X stable buildbots) and only one (an s390) running 5.x and none yet running 6.x. I don't know that we've written this policy anywhere but I think it has been our de facto policy to require only the "standard" platform build tools (including compilers) to build or install Python on our supported platform versions. With my OS X hat on, I know this likely presents an issue for the OS X installer builds. Up to now, we have been providing installers that run on all Macs that are supported back to at least OS X 10.6 and, to do that, we build on 10.6 with the standard Apple build tools available there including GCC 4.2. If GCC 4.2 proves to no longer be suitable, we'll have to make some adjustment in either what versions of OS X we support and/or how we build python.org Pythons for OS X. There are several possibilities, and, at some point, we will need to do something anyway. I am hoping to propose and implement some changes prior to 3.6.0b1 and this discussion will shape that proposal. I don't think OS X support should be a gating factor in deciding to move ahead with C99 adoption but it does point out that there might be more ramifications to this decision. What may be more difficult is to judge the impact on other platforms that don't get as much attention from most of us. For this to move forward, we need to be able to state what the impact to current users will be. -- Ned Deily nad@python.org -- []
Different question. What features are we actually talking about? Is it possible to enumerate them? The only thing I'm aware of is declarations following non-declarations in the same block, but I'm no C expert any more. On Fri, Aug 5, 2016 at 8:43 PM, Ned Deily <nad@python.org> wrote:
On Aug 5, 2016, at 23:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
As a pragmatic requirement, what if we went with:
- must compile with the Python 3.5 Windows compiler (so MSVC 14.0) - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
The reason I like the pragmatic definition is that it's one we can readily automate by ensuring these 3 configurations are always present in the stable buildbot fleet, while the formal standards based version is technically more precise, but not in a way we can easily test.
It also gives us an objective criterion for when we change the definitions: when the baseline compiler version for the respective platform builds change, and Python 3.x versions using the older definition are no longer supported by python-dev.
Phrasing the policy that way would mean moving future iterations of the manylinux spec out of distutils-sig only territory into one which needs to be reviewed by both distutils-sig and python-dev (since it would now also modify CPython's compiler compatibility requirements in PEP 7), but I think that's a reasonable position to adopt, and unlikely to cause any major problems (manylinux is a *trailing* edge definition that is only likely to get updated as the oldest enterprise Linux definitions drop out of commercial support)
The other question we need to consider is the possible impact on PEP 11: what happens to support for alternate compilers and platforms that *have* a buildbot, but may not support particular C99 features? Should there be a 4th clause that says "- must compile and run on all stable buildbots"?
[Nick's reply above arrived just as I was getting ready to send my own response below which covers some of the same territory.]
On Aug 5, 2016, at 18:37, Guido van Rossum <gvanrossum@gmail.com> wrote:
I think if we want to revisit this in the future it should be an explicit change. On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon <brett@python.org> wrote:
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens. OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum@gmail.com> wrote: the latest releases (unless I'm missing a compiler we all feel like we should officially support).
While in principle allowing C99 features to be used in cpython is a *good* thing, I'm sure that I don't fully understand all of the implications of adopting this policy for 3.6. I think we need to be sure we don't inadvertently drop support for some platforms and/or older releases of some platforms. The key word is "inadvertently". Not all of those compiler versions above are supported everywhere we currently run. If that's what we want to do, that's fine but we should be explicit about that. Two sets of concerns that come to mind are our buildbots and support for older OS X releases.
If I gathered the data correctly, for the default branch (upcoming 3.6 release), we currently have 31 buildbots: 19 classified as "stable" and 12 as "unstable". Of the stable buildbots, here is the count, version, and platform architecture of compilers in use:
2 x MSVC 14.0 2015 64 bit (AMD64) 1 x MSVC 14.0 2015 32 bit (AMD64)
1 x Clang 3.8.0 (AMD64) 1 x Clang 3.4.1 (AMD64)
1 x GCC 5.3.1 (s390x) 2 x GCC 4.9.3 (x86) 2 x GCC 4.9.2 (AMD64) 1 x GCC 4.9.2 (PPC64LE) 2 x GCC 4.8.5 (s390x) 1 x GCC 4.8.4 (x86) 1 x GCC 4.8.3 (PPC64) 1 x GCC 4.3.3 (AMD64) 2 x GCC 4.2.1 (AMD64) 1 x GCC 4.0.1 (x86)
I know very little about the details of C99 support in those compilers but I gather from this link (https://gcc.gnu.org/c99status.html) that GCC 4.5 is potentially the earliest level that properly supports C99. Note that we have a number of buildbots running version of GCC older than 4.5 (including all of our OS X stable buildbots) and only one (an s390) running 5.x and none yet running 6.x.
I don't know that we've written this policy anywhere but I think it has been our de facto policy to require only the "standard" platform build tools (including compilers) to build or install Python on our supported platform versions. With my OS X hat on, I know this likely presents an issue for the OS X installer builds. Up to now, we have been providing installers that run on all Macs that are supported back to at least OS X 10.6 and, to do that, we build on 10.6 with the standard Apple build tools available there including GCC 4.2. If GCC 4.2 proves to no longer be suitable, we'll have to make some adjustment in either what versions of OS X we support and/or how we build python.org Pythons for OS X. There are several possibilities, and, at some point, we will need to do something anyway. I am hoping to propose and implement some changes prior to 3.6.0b1 and this discussion will shape that proposal.
I don't think OS X support should be a gating factor in deciding to move ahead with C99 adoption but it does point out that there might be more ramifications to this decision. What may be more difficult is to judge the impact on other platforms that don't get as much attention from most of us. For this to move forward, we need to be able to state what the impact to current users will be.
-- Ned Deily nad@python.org -- []
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Ned Deily writes:
I don't think OS X support should be a gating factor in deciding to move ahead with C99 adoption but it does point out that there might be more ramifications to this decision.
I may be talking through my hat here, but Apple has been using LLVM for several major releases now. They seem to be keeping the GCC frontend stuck at 4.2.1, though. So just because we've been using GCC 4.2.1 on Mac, including on buildbots, doesn't mean that there is no C99 compiler available on Macs -- it's quite possible that the available clang frontend does already support the C99 features we would use. I suppose that might mean fiddling with the installer build process as well as the buildbots. Also, it seems like it's been a decade since a C compiler came standard with Mac OS X -- you need to download and install Xcode or at least xcodebuildtools separately. So unless the Macs are quite ancient (fvo ancient = 5 years old), at least at one time they were upgradeable by installing Xcode. Of course Mac users may not be willing or able to upgrade Xcode, but at least the possibility is worth investigating.
What may be more difficult is to judge the impact on other platforms that don't get as much attention from most of us. For this to move forward, we need to be able to state what the impact to current users will be.
We could post a poll to python-list (to be hosted on surveymonkey or similar, *not* back to this list!), explaining the proposal and asking "what is your platform?", "what compiler and version do you use?", "does it support C99 (perhaps with switches)?", "if not, can you upgrade to one with C99 support?", and "if you can upgrade, how much pain would it be to upgrade?" I guess the last one would take values from "I'd be annoyed for less than 10 minutes then forget it" to "enough so that I wouldn't upgrade Python". I suppose one intermediate answer might be "I'd have to maintain a separate compiler just for Python."
I think these features may improve C code readability. (Easy feature first). * // one line comment * inline function static inline function can be used instead of may macros. It is more readable, and type safe. * Designated Initializers; { .key = value }; https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html Defining new type may be much shorter. * stdint.h https://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h If we can relying to it, we can remove like PY_INT_32 * variadic macro It may reduce some wrapper functions, but I'm not sure. On Sat, Aug 6, 2016 at 1:04 PM, Guido van Rossum <guido@python.org> wrote:
Different question. What features are we actually talking about? Is it possible to enumerate them?
The only thing I'm aware of is declarations following non-declarations in the same block, but I'm no C expert any more.
On Fri, Aug 5, 2016 at 8:43 PM, Ned Deily <nad@python.org> wrote:
On Aug 5, 2016, at 23:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
As a pragmatic requirement, what if we went with:
- must compile with the Python 3.5 Windows compiler (so MSVC 14.0) - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
The reason I like the pragmatic definition is that it's one we can readily automate by ensuring these 3 configurations are always present in the stable buildbot fleet, while the formal standards based version is technically more precise, but not in a way we can easily test.
It also gives us an objective criterion for when we change the definitions: when the baseline compiler version for the respective platform builds change, and Python 3.x versions using the older definition are no longer supported by python-dev.
Phrasing the policy that way would mean moving future iterations of the manylinux spec out of distutils-sig only territory into one which needs to be reviewed by both distutils-sig and python-dev (since it would now also modify CPython's compiler compatibility requirements in PEP 7), but I think that's a reasonable position to adopt, and unlikely to cause any major problems (manylinux is a *trailing* edge definition that is only likely to get updated as the oldest enterprise Linux definitions drop out of commercial support)
The other question we need to consider is the possible impact on PEP 11: what happens to support for alternate compilers and platforms that *have* a buildbot, but may not support particular C99 features? Should there be a 4th clause that says "- must compile and run on all stable buildbots"?
[Nick's reply above arrived just as I was getting ready to send my own response below which covers some of the same territory.]
On Aug 5, 2016, at 18:37, Guido van Rossum <gvanrossum@gmail.com> wrote:
I think if we want to revisit this in the future it should be an explicit change. On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon <brett@python.org> wrote:
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens. OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum@gmail.com> wrote: the latest releases (unless I'm missing a compiler we all feel like we should officially support).
While in principle allowing C99 features to be used in cpython is a *good* thing, I'm sure that I don't fully understand all of the implications of adopting this policy for 3.6. I think we need to be sure we don't inadvertently drop support for some platforms and/or older releases of some platforms. The key word is "inadvertently". Not all of those compiler versions above are supported everywhere we currently run. If that's what we want to do, that's fine but we should be explicit about that. Two sets of concerns that come to mind are our buildbots and support for older OS X releases.
If I gathered the data correctly, for the default branch (upcoming 3.6 release), we currently have 31 buildbots: 19 classified as "stable" and 12 as "unstable". Of the stable buildbots, here is the count, version, and platform architecture of compilers in use:
2 x MSVC 14.0 2015 64 bit (AMD64) 1 x MSVC 14.0 2015 32 bit (AMD64)
1 x Clang 3.8.0 (AMD64) 1 x Clang 3.4.1 (AMD64)
1 x GCC 5.3.1 (s390x) 2 x GCC 4.9.3 (x86) 2 x GCC 4.9.2 (AMD64) 1 x GCC 4.9.2 (PPC64LE) 2 x GCC 4.8.5 (s390x) 1 x GCC 4.8.4 (x86) 1 x GCC 4.8.3 (PPC64) 1 x GCC 4.3.3 (AMD64) 2 x GCC 4.2.1 (AMD64) 1 x GCC 4.0.1 (x86)
I know very little about the details of C99 support in those compilers but I gather from this link (https://gcc.gnu.org/c99status.html) that GCC 4.5 is potentially the earliest level that properly supports C99. Note that we have a number of buildbots running version of GCC older than 4.5 (including all of our OS X stable buildbots) and only one (an s390) running 5.x and none yet running 6.x.
I don't know that we've written this policy anywhere but I think it has been our de facto policy to require only the "standard" platform build tools (including compilers) to build or install Python on our supported platform versions. With my OS X hat on, I know this likely presents an issue for the OS X installer builds. Up to now, we have been providing installers that run on all Macs that are supported back to at least OS X 10.6 and, to do that, we build on 10.6 with the standard Apple build tools available there including GCC 4.2. If GCC 4.2 proves to no longer be suitable, we'll have to make some adjustment in either what versions of OS X we support and/or how we build python.org Pythons for OS X. There are several possibilities, and, at some point, we will need to do something anyway. I am hoping to propose and implement some changes prior to 3.6.0b1 and this discussion will shape that proposal.
I don't think OS X support should be a gating factor in deciding to move ahead with C99 adoption but it does point out that there might be more ramifications to this decision. What may be more difficult is to judge the impact on other platforms that don't get as much attention from most of us. For this to move forward, we need to be able to state what the impact to current users will be.
-- Ned Deily nad@python.org -- []
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido) _______________________________________________ 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/songofacandy%40gmail.com
-- INADA Naoki <songofacandy@gmail.com>
On 06.08.2016 00:27, Brett Cannon wrote:
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum@gmail.com> wrote:
I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens.
OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are the latest releases (unless I'm missing a compiler we all feel like we should officially support).
please make that GCC 6.2 once released later this month (6.1 is the first 6.x release). GCC 5 and GCC 6 default to C11 (-std=gnu11), does the restriction to C99 mean that -std=gnu99 should be passed explicitly?
Matthias Klose <doko@ubuntu.com> wrote:
GCC 5 and GCC 6 default to C11 (-std=gnu11), does the restriction to C99 mean that -std=gnu99 should be passed explicitly?
Also note that -std=c99 is not the same as -std=gnu99. The latter allows GNU extensions like computed goto. Does the interpreter depend on those? (Presumably it could be a benefit.) Sturla
On Aug 6, 2016, at 01:16, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I may be talking through my hat here, but Apple has been using LLVM for several major releases now. They seem to be keeping the GCC frontend stuck at 4.2.1, though. So just because we've been using GCC 4.2.1 on Mac, including on buildbots, doesn't mean that there is no C99 compiler available on Macs -- it's quite possible that the available clang frontend does already support the C99 features we would use. I suppose that might mean fiddling with the installer build process as well as the buildbots.
Sorry, I wasn't clear; I did not mean to imply there is no C99 compiler available from Apple for OS X. On current OS X releases, clang is the default and only supported compiler. I was bringing up the example of the impact on building on older releases with the supported build tools for those releases where clang is either not available or was too immature to be usable. As I said, there are a number of solutions to that problem - building on newer systems with deployment targets, installing third-party compilers, etc. But the point I was trying to make is that, by changing the language requirement, we will likely have an effect on what platforms (across the board) and versions we support and we should take that into account when making this decision. It may be the right decision, in balance, to drop support for some of these but we shouldn't do it by accident. -- Ned Deily nad@python.org -- []
On Aug 6, 2016, at 00:04, Guido van Rossum <guido@python.org> wrote:
Different question. What features are we actually talking about? Is it possible to enumerate them?
The only thing I'm aware of is declarations following non-declarations in the same block, but I'm no C expert any more.
I'm certainly not, either. Looking back over the original thread, there were a number of features talked about. I think Larry's list here captures most of them: "Clearly it'll be 3.5+ only, and clearly it'll be a specific list of features ("C89 but also permitting //-comments, variadic macros, variable declarations on any line, inline functions, and designated initializers"). But I'm looking forward to it!" https://mail.python.org/pipermail/python-dev/2016-June/144831.html So, if that set of features seems reasonable, perhaps the next step is for someone (not me) to put together a test patch that incorporates the use of them and then we can run it against the buildbots, either by using the special build buildbots or just temporarily checking the patch in. I'm willing to do the testing and results-gathering if a patch is supplied. -- Ned Deily nad@python.org -- []
On Sat, 6 Aug 2016 at 10:16 Ned Deily <nad@python.org> wrote:
On Aug 6, 2016, at 00:04, Guido van Rossum <guido@python.org> wrote:
Different question. What features are we actually talking about? Is it possible to enumerate them?
The only thing I'm aware of is declarations following non-declarations in the same block, but I'm no C expert any more.
I'm certainly not, either. Looking back over the original thread, there were a number of features talked about. I think Larry's list here captures most of them:
"Clearly it'll be 3.5+ only, and clearly it'll be a specific list of features ("C89 but also permitting //-comments, variadic macros, variable declarations on any line, inline functions, and designated initializers"). But I'm looking forward to it!"
https://mail.python.org/pipermail/python-dev/2016-June/144831.html
So, if that set of features seems reasonable, perhaps the next step is for someone (not me) to put together a test patch that incorporates the use of them and then we can run it against the buildbots, either by using the special build buildbots or just temporarily checking the patch in. I'm willing to do the testing and results-gathering if a patch is supplied.
If you want to take that route then you could try temporarily patching one of the xx* modules as an example.
Ned Deily <nad@python.org> wrote:
On Aug 6, 2016, at 01:16, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I may be talking through my hat here, but Apple has been using LLVM for several major releases now. They seem to be keeping the GCC frontend stuck at 4.2.1, though. So just because we've been using GCC 4.2.1 on Mac, including on buildbots, doesn't mean that there is no C99 compiler available on Macs -- it's quite possible that the available clang frontend does already support the C99 features we would use. I suppose that might mean fiddling with the installer build process as well as the buildbots.
Sorry, I wasn't clear; I did not mean to imply there is no C99 compiler available from Apple for OS X. On current OS X releases, clang is the default and only supported compiler. I was bringing up the example of the impact on building on older releases with the supported build tools for those releases where clang is either not available or was too immature to be usable. As I said, there are a number of solutions to that problem - building on newer systems with deployment targets, installing third-party compilers, etc.
Clang is also available (and installed) on OSX 10.8 and earlier, although gcc 4.2.1 is the default frontend to LLVM. The easiest solution to get C99 on those platforms is $ export CC=clang Not very difficult, and highly recommended. Sturla Molden
"Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I may be talking through my hat here, but Apple has been using LLVM for several major releases now. They seem to be keeping the GCC frontend stuck at 4.2.1, though. So just because we've been using GCC 4.2.1 on Mac, including on buildbots, doesn't mean that there is no C99 compiler available on Macs -- it's quite possible that the available clang frontend does already support the C99 features we would use. I suppose that might mean fiddling with the installer build process as well as the buildbots.
On OSX 10.8 and earlier, the default CC is llvm-gcc-4.2.1, available as the gcc command. clang is also installed, so we can always $ export CC=clang $ export CXX=clang++ to remedy the problem. On OSX 10.9 and later, gcc is just a symlink to clang. Xcode must be installed to build anything on Mac. It is not optional. Users who need to build Python without installing Xcode need to fix their heads. Because that is where their problem resides. There is no remedy for stubbornness to the level of stupidity. Either they install Xcode or they don't get to build anything. Sturla
On Aug 6, 2016, at 17:55, Sturla Molden <sturla.molden@gmail.com> wrote:
On OSX 10.8 and earlier, the default CC is llvm-gcc-4.2.1, available as the gcc command. clang is also installed, so we can always [...]
Thanks, but this is getting way off-topic. I am well aware of what compilers are available on what releases and how to use them. That's not the issue under discussion here. -- Ned Deily nad@python.org -- []
On Sat, Aug 6, 2016 at 2:55 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
Xcode must be installed to build anything on Mac. It is not optional. Users who need to build Python without installing Xcode need to fix their heads. Because that is where their problem resides. There is no remedy for stubbornness to the level of stupidity. Either they install Xcode or they don't get to build anything.
This feels close to a code of conduct violation. This kind of language may be okay on the Linux kernel list, but I don't see the point of it here. -- --Guido van Rossum (python.org/~guido)
On Sat, Aug 6, 2016 at 5:55 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
Either they install Xcode or they don't get to build anything.
I always thought "Command Line Tools" would be enough. https://developer.apple.com/library/ios/technotes/tn2339/_index.html#//apple...
Guido van Rossum <guido@python.org> wrote:
This feels close to a code of conduct violation. This kind of language may be okay on the Linux kernel list, but I don't see the point of it here.
Sorry, I should have found a more diplomatic formulation. But the principle remains, build problems araising from missing Xcode installation should not be CPython's problem. It is ok to assume that Xcode is always installed when CPython is built on OSX.
Ned Deily writes:
But the point I was trying to make is that, by changing the language requirement, we will likely have an effect on what platforms (across the board) and versions we support and we should take that into account when making this decision. It may be the right decision, in balance, to drop support for some of these but we shouldn't do it by accident.
Sure, you were clear enough about that. My point was simply that at least for older Macs it probably is not that big a problem (but I do have a Panther still running, at least as of March it did ;-). Similarly, for platforms where we build with GCC, many of these features have been available for a long time with switches. Adding it all up, we don't want to break anybody inadvertantly and we should take care to fix what breakage we can in advance, but I think it's time to allow at least some of these features, and maybe move to C99 wholesale. Steve
On 04-Jun-16 10:12, Sebastian Krause wrote:
Sounds good for features that are well-supported by compilers that
people use. (Are there other compilers used than just GCC and MSVC?) Just thought I'd mention that "little ole me" is using IBM vac on AIX rather than gcc. This has more to do with maintaining the gcc rte requirements of anything built by gcc rather compiler features.
There is one gcc compiler feature that has proved a show-stopper - constructor - in glibc (Gnome). There they also make an exception for Windows, but not for "other" compilers. FYI: calling the IBM C compiler as c99 magically makes it c99 compliant, as xlc makes it c99 plus several extensions - and take note - as cc it is "pre-c89". In other words, calling IBM compiler as "cc" is not a wise thing to do - I recommend to anyone listing to use either "xlc" or "xlc_r". Michael
On Fri, Aug 5, 2016 at 8:02 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 6 August 2016 at 12:15, Steve Dower <steve.dower@python.org> wrote:
FYI, it's MSVC 14.0 (which is included in VS 2015).
Personally I'd like to see it restricted to the common subset of C99 and some version of C++ (which is obviously mostly C and includes no C++), because I know there are a few things in C99 only that are very obscure because they aren't also in C++.
As a pragmatic requirement, what if we went with:
- must compile with the Python 3.5 Windows compiler (so MSVC 14.0) - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
The reason I like the pragmatic definition is that it's one we can readily automate by ensuring these 3 configurations are always present in the stable buildbot fleet, while the formal standards based version is technically more precise, but not in a way we can easily test.
This approach makes a lot of sense to me. In particular it seems like it can avoid getting bogged down in a lot of questions about the theoretical idea of C99, which is often somewhat unclear. I wrote a little test file for all the C99 features that were mentioned in this thread (I think): https://gist.github.com/njsmith/f666671de31f35644bb91a815c9cad75 Ned reports that our OS X compiler is currently GCC 4.2, and that this doesn't officially support "C99" -- but I just checked and it happily builds that file :-). (Judging from [1], it looks like the major feature missing in 4.2 was support for C99's more obscure inlining semantics; but I think we only really care about 'static inline' specifically, and that appears to be unchanged [2].)
Phrasing the policy that way would mean moving future iterations of the manylinux spec out of distutils-sig only territory into one which needs to be reviewed by both distutils-sig and python-dev (since it would now also modify CPython's compiler compatibility requirements in PEP 7), but I think that's a reasonable position to adopt, and unlikely to cause any major problems (manylinux is a *trailing* edge definition that is only likely to get updated as the oldest enterprise Linux definitions drop out of commercial support)
With my manylinux maintainer hat on, I don't think there'd be any problem with bringing python-dev into those discussions. But note that technically, the manylinux1 spec doesn't say what compiler you can use; it says that whatever compiler you use has to generate binaries that work on CentOS 5. (Why CentOS 5? Because it's the oldest non-EOL linux distribution in common use; manylinux2 will presumably bump the requirement to CentOS 6 once CentOS 5 goes EOL). The reason this matters is that the official vendor compiler on RHEL 5 is gcc 4.1, but there's also a separately-distributed version of gcc 4.8.2 that can target it. If a packager trying to build manylinux wheels wants a more modern gcc, then it's reasonable to ask them to get this patched gcc. But for an end-user who's just trying to build CPython on their machine, you might or might not consider this an acceptable request -- maybe CPython wants to work on default vendor compiler to imposing that on users. And in practice this almost certainly doesn't matter -- the only reason people jump through hoops to get gcc 4.8 is for its improved C++ support. I just tried my c99 test file on CentOS 5's default gcc 4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for 3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4, which is even less of a worry. tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4" should be a fine rule that works for everyone. But I guess we probably also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases. -n [1] https://gcc.gnu.org/c99status.html [2] "The [different versions] of inlining behave similarly ... when the inline keyword is used on a static function" -- https://gcc.gnu.org/onlinedocs/gcc/Inline.html -- Nathaniel J. Smith -- https://vorpus.org
On Thu, Oct 6, 2016 at 10:10 PM, Nathaniel Smith <njs@pobox.com> wrote: [...]
And in practice this almost certainly doesn't matter -- the only reason people jump through hoops to get gcc 4.8 is for its improved C++ support. I just tried my c99 test file on CentOS 5's default gcc 4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for 3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4, which is even less of a worry.
tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4" should be a fine rule that works for everyone. But I guess we probably also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.
Doh, I have an off-by-one error, and wrote 3.5/3.6 where I meant 3.6/3.7. If the change is on the table for 3.6, then I guess I'd suggest continuing to support gcc 4.1 through the 3.6 support lifecycle, since I believe CentOS/RHEL 5 are considered supported platforms for 3.6, and the burden of doing this is probably very small. In particular, it doesn't seem to block any C99 features that we care about. (Is the list of supported platforms for Linux documented anywhere? PEP 11 documents the rule for Windows, and I'm assuming that the same rule applies to RHEL.) -n -- Nathaniel J. Smith -- https://vorpus.org
On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote:
The reason this matters is that the official vendor compiler on RHEL 5 is gcc 4.1, but there's also a separately-distributed version of gcc 4.8.2 that can target it.
Where can I get that 4.8 for RHEL 5? I'm using Centos 5, which ought to be the same as RHEL 5, and the standard gcc is 4.1, with 4.4 available through yum. If 4.8 is available anywhere, I haven't been able to find it. And as far as I can see, 3.6 won't build under either 4.1 or 4.4 on Centos 5.
If a packager trying to build manylinux wheels wants a more modern gcc, then it's reasonable to ask them to get this patched gcc. But for an end-user who's just trying to build CPython on their machine, you might or might not consider this an acceptable request -- maybe CPython wants to work on default vendor compiler to imposing that on users.
And in practice this almost certainly doesn't matter -- the only reason people jump through hoops to get gcc 4.8 is for its improved C++ support. I just tried my c99 test file on CentOS 5's default gcc 4.1 and it was fine.
Can you try building Python 3.6? Because it fails for me, and the discussion here: http://bugs.python.org/issue28092 concluded that 4.1 is not supported and I'm right out of luck until I can upgrade. -- Steve
On Sat, Oct 8, 2016 at 9:23 AM, Steven D'Aprano <steve@pearwood.info> wrote: > On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote: > >> The reason this matters is that the official vendor compiler on RHEL 5 >> is gcc 4.1, but there's also a separately-distributed version of gcc >> 4.8.2 that can target it. > > Where can I get that 4.8 for RHEL 5? > > I'm using Centos 5, which ought to be the same as RHEL 5, and the > standard gcc is 4.1, with 4.4 available through yum. If 4.8 is available > anywhere, I haven't been able to find it. And as far as I can see, 3.6 > won't build under either 4.1 or 4.4 on Centos 5. It's RH's "devtoolset" release. The build scripts for the manylinux docker images demonstrate how to install them: https://github.com/pypa/manylinux/blob/master/docker/build_scripts/build.sh#L38 (Unfortunately this involves installing them from a random CentOS dev's home directory over plain-HTTP, but that's the only way to get them if you don't have the appropriate RHEL subscription -- see https://github.com/pypa/manylinux/issues/46#issuecomment-205054077) >> If a packager trying to build manylinux >> wheels wants a more modern gcc, then it's reasonable to ask them to >> get this patched gcc. But for an end-user who's just trying to build >> CPython on their machine, you might or might not consider this an >> acceptable request -- maybe CPython wants to work on default vendor >> compiler to imposing that on users. >> >> And in practice this almost certainly doesn't matter -- the only >> reason people jump through hoops to get gcc 4.8 is for its improved >> C++ support. I just tried my c99 test file on CentOS 5's default gcc >> 4.1 and it was fine. > > Can you try building Python 3.6? Because it fails for me, and the > discussion here: > > http://bugs.python.org/issue28092 > > concluded that 4.1 is not supported and I'm right out of luck until I > can upgrade. I don't have time to follow up right now, but something like docker run -v $PWD:/io -it --rm quay.io/pypa/manylinux1_x86_64 /bin/bash should drop you into a shell in a temporary centos5 VM where 'gcc' is 4.8.2. >From the bug report it sounds like the issue is that my comments above about 'we only care about static inline' were wrong, or at least, Benjamin disagrees :-). I guess the revised version is - if we insist on full C99 inline support, then that means dropping support for building with vendor gcc on CentOS 5 and OS X (and possibly dropping support for older OS X altogether?) - if we are willing to restrict ourselves to 'static inline' and forgo the other 'inline' variants, then all the other C99 things we care about are fine and we can keep support for vendor gcc on CentOS 5 and OS X. -n -- Nathaniel J. Smith -- https://vorpus.org
participants (28)
-
Alexander Belopolsky -
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
Dino Viehland -
Eric V. Smith -
Guido van Rossum -
Guido van Rossum -
INADA Naoki -
Larry Hastings -
Martin Panter -
Matthias Klose -
Meador Inge -
Michael Felt -
Nathaniel Smith -
Ned Deily -
Nick Coghlan -
Random832 -
Sebastian Krause -
Stefan Krah -
Stephen J. Turnbull -
Steve Dower -
Steven D'Aprano -
Sturla Molden -
Terry Reedy -
tritium-list＠sdamon.com -
Victor Stinner -
Émanuel Barry