[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On 23Feb2022 2240, h.vetin...@gmx.com wrote: On top of that, I think the formulation you chose does not map correctly to actual compiler capabilities. C99 (minus C11 optionals) only arrived in VS2019, there were still gaps in VS2017. Additionally, Visual Studio version doesn't directly map to the compiler version. For example, VS2022 contains multiple older versions of the compiler. Currently we use the v142 toolset for releases (selected by default in desktop development workloads in VS 2019), and can't migrate to v143 (selected by default in VS 2022) until some compiler bugs are fixed. If we're going to specify anything about MSVC, I'd prefer it was the v142 label rather than the Visual Studio version (though we can include the latter as a convenience for the reader, and hopefully clearly enough that people stop filing bug reports about it...) Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KJ5XCX7IOV6GR2MWPXV6TNJ3P5G5NLSW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Thu, Feb 24, 2022 at 3:27 PM Victor Stinner wrote: > On Thu, Feb 24, 2022 at 11:10 PM Barry wrote: > > > "Python 3.11 and newer versions use C11 without optional features. The > > > public C API should be compatible with C++." > > > https://github.com/python/peps/pull/2309/files > > > > Should is often read as meaning optional when writing specs. > > Can you say “must be compatible with C++”. > > I plan to attempt to write an actual test for that, rather than a > vague sentence in a PEP. For now, "should" is a deliberate choice: I > don't know exactly which C++ version should be targeted and if it's > really an issue or not. > Agreed. "should" is good because we're not even clear if we currently actually comply with C++ standards. i.e. https://bugs.python.org/issue40120 suggests we technically may not for C++ (it is not strictly a superset of C as we all like to pretend), though for practical purposes regardless of standards compilers tend to allow that. We're likely overspecifying in any document we create about what we require because the only definition any of us are actually capable of making for what we require is "does it compile with this compiler on this platform? If yes, then we appear to support it. can we guarantee that? only with buildbots or other CI" - We're generally not versed in specific language standards (aside from compiler folks, who is?), and compilers don't comply strictly with all the shapes of those anyways for either practical or hysterical reasons. So no matter what we claim to aspire to, reality is always murkier. A document about requirements is primarily useful to give guidance to what we expect to be aligned with and what is or isn't allowed to be used in new code. Our code itself always has the final say. -gps > For example, C++20 reserves the "module" keyword, whereas Python uses > it in its C API. Example: > > PyAPI_FUNC(int) PyModule_AddType(PyObject *module, PyTypeObject *type); > > See: > > * https://bugs.python.org/issue39355 > * https://github.com/pythoncapi/pythoncapi_compat/issues/21 > > -- > > I made a change in the datatable project to add Python 3.11 support > using the pythoncapi_compat.h header file. Problem: this *C* header > file produced new warnings in datatable extension module which with > built with a C++ compiler: > https://github.com/h2oai/datatable/pull/3231#issuecomment-1032864790 > > Examples: > > | src/core/lib/pythoncapi_compat.h:272:52: warning: zero as null > pointer constant [-Wzero-as-null-pointer-constant] > ||| tstate->c_profilefunc != NULL); > |^~~~ > |nullptr > > and > > | src/core/lib/pythoncapi_compat.h:170:12: warning: use of old-style > cast [-Wold-style-cast] > | return (PyCodeObject *)_Py_StealRef(PyFrame_GetCode(frame)); > |^ > > I made pythoncapi_compat.h compatible with C++ (fix C++ compiler > warnings) by using nullptr and reinterpret_cast(EXPR) cast if > the __cplusplus macro is defined, or NULL and ((TYPE)(EXPR)) cast > otherwise. > > datatable also uses #include "Python.h". I don't know there were only > C++ compiler warnings on "pythoncapi_compat.h". Maybe because > datatable only uses static inline functions from > "pythoncapi_compat.h", but it may also emit the same warnings if > tomorrow some static inline functions of "Python.h" are used. > > For now, I prefer to put a reminder in PEP 7 that the "Python.h" C API > is consumed by C++ projects. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/RGNBM5CSUPBQSTZND4PHEV3WUEKS36TP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XUPAVKB7S2NCOGQY2JUMDBSTJADIOBPY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Thu, Feb 24, 2022 at 11:10 PM Barry wrote: > > "Python 3.11 and newer versions use C11 without optional features. The > > public C API should be compatible with C++." > > https://github.com/python/peps/pull/2309/files > > Should is often read as meaning optional when writing specs. > Can you say “must be compatible with C++”. I plan to attempt to write an actual test for that, rather than a vague sentence in a PEP. For now, "should" is a deliberate choice: I don't know exactly which C++ version should be targeted and if it's really an issue or not. For example, C++20 reserves the "module" keyword, whereas Python uses it in its C API. Example: PyAPI_FUNC(int) PyModule_AddType(PyObject *module, PyTypeObject *type); See: * https://bugs.python.org/issue39355 * https://github.com/pythoncapi/pythoncapi_compat/issues/21 -- I made a change in the datatable project to add Python 3.11 support using the pythoncapi_compat.h header file. Problem: this *C* header file produced new warnings in datatable extension module which with built with a C++ compiler: https://github.com/h2oai/datatable/pull/3231#issuecomment-1032864790 Examples: | src/core/lib/pythoncapi_compat.h:272:52: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] ||| tstate->c_profilefunc != NULL); |^~~~ |nullptr and | src/core/lib/pythoncapi_compat.h:170:12: warning: use of old-style cast [-Wold-style-cast] | return (PyCodeObject *)_Py_StealRef(PyFrame_GetCode(frame)); |^ I made pythoncapi_compat.h compatible with C++ (fix C++ compiler warnings) by using nullptr and reinterpret_cast(EXPR) cast if the __cplusplus macro is defined, or NULL and ((TYPE)(EXPR)) cast otherwise. datatable also uses #include "Python.h". I don't know there were only C++ compiler warnings on "pythoncapi_compat.h". Maybe because datatable only uses static inline functions from "pythoncapi_compat.h", but it may also emit the same warnings if tomorrow some static inline functions of "Python.h" are used. For now, I prefer to put a reminder in PEP 7 that the "Python.h" C API is consumed by C++ projects. Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RGNBM5CSUPBQSTZND4PHEV3WUEKS36TP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
> On 24 Feb 2022, at 11:45, Victor Stinner wrote: > > Ok, let me try something simpler: > > "Python 3.11 and newer versions use C11 without optional features. The > public C API should be compatible with C++." > https://github.com/python/peps/pull/2309/files Should is often read as meaning optional when writing specs. Can you say “must be compatible with C++”. Barry > > Victor > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/C32XCK5WHMLJNV6RGLMN2XNBDWR4DI3V/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AKW6Y5TIHWIZKCSQD4I6GD4Q7GZQYUZ7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
Ok, let me try something simpler: "Python 3.11 and newer versions use C11 without optional features. The public C API should be compatible with C++." https://github.com/python/peps/pull/2309/files Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C32XCK5WHMLJNV6RGLMN2XNBDWR4DI3V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
> And it seems like we still care about support Visual Studio 2017, even > if Visual Studio 2019 and 2022 are available. Can we make this more concrete? Do we know of affected parties? Numbers of affected users? Or are we just conservatively guesstimating the thickness of the long tail of support? On top of that, I think the formulation you chose does not map correctly to actual compiler capabilities. C99 (minus C11 optionals) only arrived in VS2019, there were still gaps in VS2017. I would advocate bumping the requirement to VS2019. Yes, there is a built-in reluctance to update toolchains, but MSFT has been _extremely_ conservative w.r.t. ABI-compatibility (e.g. the whole story with [[msvc::no_unique_address]]), and I just don't see the argument why a non-negligible portion of users cannot upgrade to the fully-compatible-with-everything-previously VS2019. > "Python 3.11 and newer versions use C99 in the public C API and use a > subset of C11 in Python internals. The public C API should be > compatible with C++. The C11 subset are features supported by GCC 8.5, > clang 8.0, and MSVC of Visual Studio 2017." If we were to require VS2019, then the formulation could be much nicer (IMO): """ Python 3.11 and newer versions use C99 in the public C API (without those features that became optional in C11), while Python internals may use C11 (again without optional features). The public C API should be compatible with C++. """ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PAIVGORIDRIGLPCSQI5KN6U6CKFTBHPX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
Hi, I updated my PEP 7 PR to use C99 in the public C API and "a subset of" C11 in Python internals: "Python 3.11 and newer versions use C99 in the public C API and use a subset of C11 in Python internals. The public C API should be compatible with C++. The C11 subset are features supported by GCC 8.5, clang 8.0, and MSVC of Visual Studio 2017." https://github.com/python/peps/pull/2309/files GCC 8.5 is the version chosen by RHEL 8. It should provide C11 features that we care about. I pickled clang 8.0 because it's had been released in 2019 and so should be available on most operating systems. FreeBSD uses clang by default. FreeBSD 13 uses clang 11. And it seems like we still care about support Visual Studio 2017, even if Visual Studio 2019 and 2022 are available. I chose to not require supporting AIX XLC. Inada-san wrote: "xlclang fully supports C89/C99/C11. xlc fully supports C89/C99, and partially supports C11." I guess that in practice, we can test a PR on buildbots when trying "new shiny" C11 feature. Moreover, if a C11 feature is missing, it's usually not too complicated to use a workaround for C99 and older. Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5IUV6IEB2ARZ4R6MCVK7FZFKRLH7M5NV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Wed, 09 Feb 2022 03:39:42 - h.vetin...@gmx.com wrote: > > That is becoming dated quickly, as Microsoft has deprecated, and is removing, > that version quite rapidly from their CI services (azure/GHA), i.e. mid > March, see: > https://github.com/actions/virtual-environments/issues/4312. > > It's understandable in the sense that they don't want to support a third > version > in addition to vs2022 and vs2019, but the net effect is that very few (open > source) > projects will keep using vs2017 going forward. Not every project using CPython is an open source project, though. And CPython probably supports more platforms than GHA or Azure do. Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FRC6L4QON4TPBPSJCOUSJNRWHLBS5LCB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
IMO we need to distinguish the public C API which should be as much compatible as possible, target the oldest C standard, and the Python internals can require a more recent C standard. For example, today maybe it's reasonable to requires C99 for Include/ headers (public .h files) and support C11 for Python internals (private .c files). Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LG5WBBU5JK44IO6UCKSQEUVCJ55X6ZBE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Thu, Feb 10, 2022 at 6:31 PM Petr Viktorin wrote: > > > > > I like it. I want to use anonymous union. It makes complex structure > > like PyDictKeysObject simple a little. > > > > I confirmed that XLC supports it. > > https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=types-structures-unions#strct__anonstruct > > Ah, I've also wanted anonymous unions in the past! > There's a little problem in that they're not valid in C++, so we can't > have them in public headers. > C++ 11 supports anonymous union with some reasonable limitations. https://en.cppreference.com/w/cpp/language/union XL C/C++ also support it. So we can use it if we decided to use it. Regards, -- Inada Naoki ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GE3RFUXUDFY3GZQHFEVZAIQW3CCMLFK7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Thu, Feb 10, 2022 at 10:28 AM Petr Viktorin wrote: > Ah, I've also wanted anonymous unions in the past! > There's a little problem in that they're not valid in C++, so we can't > have them in public headers. > > We'll need to mention C++ if we update the standard. IMO we only have to care about C++ in Include/ header files: make sure that "Python.h" is usable in C++. Outside this directory, we don't have to care about C++ compatibility. Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYRNS2PGB6MOUPEY5IJXFMGEVW4T5L6E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On 10. 02. 22 0:30, Inada Naoki wrote: On Thu, Feb 10, 2022 at 3:49 AM Brett Cannon wrote: On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote: On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: That's an interesting idea -- what's keeping us from C11? No one asking before, probably because we have been trying to get to C99 for so long. In other words: the main thing keeping us from C99 is MSVC support, and since that compiler apparently skipped C99, should we skip it as well? If we think "C11 without optional features" is widely supported then I think that's a fine target to have. For anyone not sure what's optional in C11, I found https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features . Other than atomics being discussed on Discord for mimalloc, leaving those things out seem reasonable to me. I like it. I want to use anonymous union. It makes complex structure like PyDictKeysObject simple a little. I confirmed that XLC supports it. https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=types-structures-unions#strct__anonstruct Ah, I've also wanted anonymous unions in the past! There's a little problem in that they're not valid in C++, so we can't have them in public headers. We'll need to mention C++ if we update the standard. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XLRK7P3Q4ANNC4ZEIPIHWJHFKFCWWMRD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Thu, Feb 10, 2022 at 3:49 AM Brett Cannon wrote: > On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote: >> On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: >> >> That's an interesting idea -- what's keeping us from C11? > > No one asking before, probably because we have been trying to get to C99 for > so long. > >> In other words: the main thing keeping us from C99 is MSVC support, and >> since that compiler apparently skipped C99, should we skip it as well? > > If we think "C11 without optional features" is widely supported then I think > that's a fine target to have. > > For anyone not sure what's optional in C11, I found > https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features > . Other than atomics being discussed on Discord for mimalloc, leaving those > things out seem reasonable to me. > I like it. I want to use anonymous union. It makes complex structure like PyDictKeysObject simple a little. I confirmed that XLC supports it. https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=types-structures-unions#strct__anonstruct Regards, -- Inada Naoki ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MMTUDLFIB7ET6T3Q73HDLODDGZY74X54/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote: > > > On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: > >> Maybe a more practical approach would be to use C99 "except of > > features not supported by MSVC of Visual Studio 2019"? > > > > This could be formulated in a more neutral way by saying > > > > "C99 without the things that became optional in C11", or perhaps > > That sounds like a better wording! > > > "C11 without optional features" (at least from the POV of MSVC, > > haven't checked the other compilers/platforms for C11-compliance). > > That's an interesting idea -- what's keeping us from C11? > No one asking before, probably because we have been trying to get to C99 for so long. > In other words: the main thing keeping us from C99 is MSVC support, and > since that compiler apparently skipped C99, should we skip it as well? > If we think "C11 without optional features" is widely supported then I think that's a fine target to have. For anyone not sure what's optional in C11, I found https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features . Other than atomics being discussed on Discord for mimalloc, leaving those things out seem reasonable to me. -Brett > > > >> In practice, we can try to support VS 2017, the version currently > > recommended by the devguide: > > > > That is becoming dated quickly, as Microsoft has deprecated, and is > removing, > > that version quite rapidly from their CI services (azure/GHA), i.e. mid > March, see: > > https://github.com/actions/virtual-environments/issues/4312. > > > > It's understandable in the sense that they don't want to support a third > version > > in addition to vs2022 and vs2019, but the net effect is that very few > (open source) > > projects will keep using vs2017 going forward. > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/IIZ6LXK2MANUHZAMYSXDF5KPF3VIRKDJ/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ERQQFXNAGANR2ND3SRDVCIQZKYTT6OBM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SV7M2CXVULHVG4X6SXZV7ZR5Y4TD3IBR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: Maybe a more practical approach would be to use C99 "except of features not supported by MSVC of Visual Studio 2019"? This could be formulated in a more neutral way by saying "C99 without the things that became optional in C11", or perhaps That sounds like a better wording! "C11 without optional features" (at least from the POV of MSVC, haven't checked the other compilers/platforms for C11-compliance). That's an interesting idea -- what's keeping us from C11? In other words: the main thing keeping us from C99 is MSVC support, and since that compiler apparently skipped C99, should we skip it as well? In practice, we can try to support VS 2017, the version currently recommended by the devguide: That is becoming dated quickly, as Microsoft has deprecated, and is removing, that version quite rapidly from their CI services (azure/GHA), i.e. mid March, see: https://github.com/actions/virtual-environments/issues/4312. It's understandable in the sense that they don't want to support a third version in addition to vs2022 and vs2019, but the net effect is that very few (open source) projects will keep using vs2017 going forward. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IIZ6LXK2MANUHZAMYSXDF5KPF3VIRKDJ/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ERQQFXNAGANR2ND3SRDVCIQZKYTT6OBM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
> Maybe a more practical approach would be to use C99 "except of features not supported by MSVC of Visual Studio 2019"? This could be formulated in a more neutral way by saying "C99 without the things that became optional in C11", or perhaps "C11 without optional features" (at least from the POV of MSVC, haven't checked the other compilers/platforms for C11-compliance). > In practice, we can try to support VS 2017, the version currently recommended by the devguide: That is becoming dated quickly, as Microsoft has deprecated, and is removing, that version quite rapidly from their CI services (azure/GHA), i.e. mid March, see: https://github.com/actions/virtual-environments/issues/4312. It's understandable in the sense that they don't want to support a third version in addition to vs2022 and vs2019, but the net effect is that very few (open source) projects will keep using vs2017 going forward. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IIZ6LXK2MANUHZAMYSXDF5KPF3VIRKDJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Tue, Feb 8, 2022 at 2:02 PM Steve Dower wrote: > All the C99 library is supposedly supported, but there are (big?) gaps > in the compiler support. Some Visual Studio 2019 updates on the Microsoft blog. March 2020: C99 _Pragma https://devblogs.microsoft.com/cppblog/announcing-full-support-for-a-c-c-conformant-preprocessor-in-msvc/ > The _Pragma operator has been one of the long-standing deficiencies of the > preprocessor, and a blocker in being standard conformant in C++ and C99. September 2020: C11 and C17 https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ Maybe a more practical approach would be to use C99 "except of features not supported by MSVC of Visual Studio 2019"? In practice, we can try to support VS 2017, the version currently recommended by the devguide: https://devguide.python.org/setup/#windows-compiling We already have fallbacks for compilers which don't support C99. We don't have to remove these fallbacks if they are still needed by popular C compilers. For example, I'm fine with keeping basic compatbility support with ICC if it remains reasonable, even if we don't "officially" support ICC (ex: no buildbot). Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/L5TIKLYYAHGCSUUWFHXW4ZBHH2TDIHUB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
According to the docs[^1], MSVC does _not_ support all of C99. OTOH they claim conformance with both C11 and C17, using the /std:c11 and /std:c17 compiler flags. [^1]: https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170 > On 8 Feb 2022, at 10:52, Petr Viktorin wrote: > > Does MSVC support all of C99? I haven't found any documentation claiming > that... but I'm also not familiar with MSVC. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYZC3F73THZXNMSYWSFPXFKAUQ5NBTDO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On 2/8/2022 9:52 AM, Petr Viktorin wrote: On 07. 02. 22 18:09, Victor Stinner wrote: In 2022, C99 is now well supported by C compilers supported by Python: GCC, clang, MSVC. Does MSVC support all of C99? I haven't found any documentation claiming that... but I'm also not familiar with MSVC. Do we need to support a subset like "C99 except the features that were removed in C11"? I couldn't find any information either (from public sources, at least, haven't asked the team directly yet). All the C99 library is supposedly supported, but there are (big?) gaps in the compiler support. Possibly these are features that were removed in C11? I don't know what is on that list. It seems C11 and C17 are supported [1], though I know for sure we have contributors who aren't using a recent enough compiler version to have it :) Personally, I see no reason to "require" C99 as a whole. We have a style guide already, and can list the additional compiler features that we allow along with guidance on updating existing code and ensuring compatibility. I don't see much risk requiring the C99 standard library, though. It's the compiler features that seem to have less coverage. Cheers, Steve [1]: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UZACKMZGN2PUGNQ74FQX2V4UTQAA6DWB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On 07. 02. 22 18:09, Victor Stinner wrote: Hi, I made a change to require C99 "NAN" constant and I'm was asked to update the PEP 7 to clarify the C subset is needed to build Python 3.11. Python 3.6 requires a subset of the C99 standard to build defined by the PEP 7: https://www.python.org/dev/peps/pep-0007/ I modified Python 3.11 to require more C99 features of the header: * bpo-45440: copysign(), hypot(), isfinite(), isinf(), isnan(), round() * bpo-46640: NAN After my NAN change (bpo-46640), Petr Viktorin asked me to update the PEP 7. I proposed a change to simply say that "Python 3.11 and newer versions use C99": https://github.com/python/peps/pull/2309 I would prefer to not have to give an exhaustive list of C99 features used by CPython, since it's unclear to me what belongs to C99 or to ISO C89. As I wrote before, Python already uses C99 features since Python 3.6. On my PEP PR, Guido van Rossum asked me to escalate the discussion to python-dev, so here I am :-) In "C99", the number "99" refers to the year 1999, the standard is now 23 years old: https://en.wikipedia.org/wiki/C99 In 2022, C99 is now well supported by C compilers supported by Python: GCC, clang, MSVC. Does MSVC support all of C99? I haven't found any documentation claiming that... but I'm also not familiar with MSVC. Do we need to support a subset like "C99 except the features that were removed in C11"? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XUNLZB5Q5BCWLX7C77WBD34ZU33RPVNM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
07.02.22 19:09, Victor Stinner пише: > After my NAN change (bpo-46640), Petr Viktorin asked me to update the > PEP 7. I proposed a change to simply say that "Python 3.11 and newer > versions use C99": But public headers should be compatible with C++, and not all C99 features are compatible with C++. It is not a matter of style, it is a matter of compatibility. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZDGZN46UQAPJY5EF5A3GYA5DT4XX6AQO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
https://www.ibm.com/docs/en/SSGH3R_16.1.0/pdf/getstart.pdf As far as reading page 3, xlclang fully supports C89/C99/C11. xlc fully supports C89/C99, and partially supports C11. On Tue, Feb 8, 2022 at 8:57 AM Brett Cannon wrote: > > > > On Mon, Feb 7, 2022 at 9:12 AM Victor Stinner wrote: >> >> Hi, >> >> I made a change to require C99 "NAN" constant and I'm was >> asked to update the PEP 7 to clarify the C subset is needed to build >> Python 3.11. >> >> Python 3.6 requires a subset of the C99 standard to build defined by the PEP >> 7: >> https://www.python.org/dev/peps/pep-0007/ >> >> I modified Python 3.11 to require more C99 features of the header: >> >> * bpo-45440: copysign(), hypot(), isfinite(), isinf(), isnan(), round() >> * bpo-46640: NAN >> >> After my NAN change (bpo-46640), Petr Viktorin asked me to update the >> PEP 7. I proposed a change to simply say that "Python 3.11 and newer >> versions use C99": >> https://github.com/python/peps/pull/2309 >> >> I would prefer to not have to give an exhaustive list of C99 features >> used by CPython, since it's unclear to me what belongs to C99 or to >> ISO C89. As I wrote before, Python already uses C99 features since >> Python 3.6. >> >> On my PEP PR, Guido van Rossum asked me to escalate the discussion to >> python-dev, so here I am :-) >> >> In "C99", the number "99" refers to the year 1999, the standard is now >> 23 years old: >> https://en.wikipedia.org/wiki/C99 >> >> In 2022, C99 is now well supported by C compilers supported by Python: >> GCC, clang, MSVC. > > > I think if those compilers fully C99 at this point we should consider just > moving completely over to C99. > > -Brett > >> >> >> I don't know if AIX XLC supports C99. AIX provides a "c99" compiler >> compatible with C99. It also seems like GCC is usable on AIX. >> >> I don't know if ICC supports C99. Python doesn't officially the ICC >> compiler, the ICC buildbots are gone a few years ago. But sometimes I >> make some changes to enhance the ICC support, when the change is small >> enough. >> >> Note: Python also uses C11 , but it's not required: there >> are fallbacks for compilers which don't support it. >> >> Victor >> -- >> Night gathers, and now my watch begins. It shall not end until my death. >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ZLDOBJUVMTIRETVRNHPWWO5MBHTXYEW3/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Inada Naoki ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XIMQWFVP7RJW7CTV74YPWI74L7ZUU2PX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Mon, Feb 7, 2022 at 9:12 AM Victor Stinner wrote: > Hi, > > I made a change to require C99 "NAN" constant and I'm was > asked to update the PEP 7 to clarify the C subset is needed to build > Python 3.11. > > Python 3.6 requires a subset of the C99 standard to build defined by the > PEP 7: > https://www.python.org/dev/peps/pep-0007/ > > I modified Python 3.11 to require more C99 features of the header: > > * bpo-45440: copysign(), hypot(), isfinite(), isinf(), isnan(), round() > * bpo-46640: NAN > > After my NAN change (bpo-46640), Petr Viktorin asked me to update the > PEP 7. I proposed a change to simply say that "Python 3.11 and newer > versions use C99": > https://github.com/python/peps/pull/2309 > > I would prefer to not have to give an exhaustive list of C99 features > used by CPython, since it's unclear to me what belongs to C99 or to > ISO C89. As I wrote before, Python already uses C99 features since > Python 3.6. > > On my PEP PR, Guido van Rossum asked me to escalate the discussion to > python-dev, so here I am :-) > > In "C99", the number "99" refers to the year 1999, the standard is now > 23 years old: > https://en.wikipedia.org/wiki/C99 > > In 2022, C99 is now well supported by C compilers supported by Python: > GCC, clang, MSVC. I think if those compilers fully C99 at this point we should consider just moving completely over to C99. -Brett > > I don't know if AIX XLC supports C99. AIX provides a "c99" compiler > compatible with C99. It also seems like GCC is usable on AIX. > > I don't know if ICC supports C99. Python doesn't officially the ICC > compiler, the ICC buildbots are gone a few years ago. But sometimes I > make some changes to enhance the ICC support, when the change is small > enough. > > Note: Python also uses C11 , but it's not required: there > are fallbacks for compilers which don't support it. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZLDOBJUVMTIRETVRNHPWWO5MBHTXYEW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner vstin...@python.org wrote: > I made a change to require C99 "NAN" constant and I'm was > asked to update the PEP 7 to clarify the C subset is needed to build > Python 3.11. What if it was built with MSVC which is usually just C90? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JSQX3OY4XMTBLLCERP3JDJXPPT2BMQQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
