Re: [Python-Dev] Status of the Argument Clinic DSL
On 5 August 2016 at 09:12, Larry Hastings wrote: > / is the delimiter between positional-only parameters and > positional-or-keyword arguments. It's not actual Python syntax, but Guido > said (somewhere) that *if* Python ever sprouted a syntax for positional-only > parameters, that was as good a delimiter as any. I think he picked it > because / is the inverse of *. I was thinking Guido picked the "/" symbol when we were discussing the Argument Clinic DSL at PyCon 2014 and you had also been working on https://www.python.org/dev/peps/pep-0457/ However, re-reading the latter shows it dates back earlier than that: https://www.python.org/dev/peps/pep-0457/#guido > If you have more questions about __text_signature__, I recommend reading the > implementation of inspect.signature, since that's the one and only consumer > of it. I occasionally wonder if we should document the "/" notation in https://docs.python.org/3/library/inspect.html#introspecting-callables-with-the-signature-object as it can sometimes show up in the text representation of signature objects: >>> print(inspect.signature(format)) (value, format_spec='', /) Likewise for describing the option of using __text_signature__ to override the default inspect.signature() output (and perhaps adding a public "inspect.Signature.from_text" alternate constructor at the same time). However, either notion is a bit tricky while PEP 457 is still in draft rather than accepted - even if it's "just" a syntax for overriding inspect.signature, we'd still be effectively locking this in as *the* syntax for positional-only arguments (if they're ever added) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the Argument Clinic DSL
On 08/04/2016 11:58 PM, Nick Coghlan wrote: I occasionally wonder if we should document the "/" notation in https://docs.python.org/3/library/inspect.html#introspecting-callables-with-the-signature-object as it can sometimes show up in the text representation of signature objects: >>> print(inspect.signature(format)) (value, format_spec='', /) I think we probably should. After all, this same string is used for pydoc: >>> import os >>> help(os.execv) Help on built-in function execv in module posix: execv(path, argv, /) Execute an executable path with arguments, replacing current process. path Path of executable file. argv Tuple or list of strings. so it's easily user-visible. I've always found it a little strange that the signatures for functions using Py_ArgParseTuple() had this / in them that wasn't Python syntax. On the other hand, it accurately reflects the fact that these functions have signatures that you can't write in Python. (And, FWIW, I wasn't the person who added the code that made "/" start showing up in the text representations of signatures. I was waffling on it, then someone else JFDI, to quote Barry.) //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-07-29 - 2016-08-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5589 ( +1) closed 33862 (+44) total 39451 (+45) Open issues with patches: 2445 Issues opened (26) == #27650: Implement `__repr__` methods for logging.Logger and others http://bugs.python.org/issue27650 opened by cool-RR #27653: [Patch] Also disable the use of on CloudABI http://bugs.python.org/issue27653 opened by EdSchouten #27654: [Patch] Use arc4random_buf() on CloudABI http://bugs.python.org/issue27654 opened by EdSchouten #27655: [Patch] Don't require presence of POLLPRI http://bugs.python.org/issue27655 opened by EdSchouten #27657: urlparse fails if the path is numeric http://bugs.python.org/issue27657 opened by Björn.Lindqvist #27658: python 3.5.2 built from source fails to install completely on http://bugs.python.org/issue27658 opened by Mario Grgic #27659: Check for the existence of crypt() http://bugs.python.org/issue27659 opened by Chi Hsuan Yen #27660: Replace size_t with Py_ssize_t as the type of local variable i http://bugs.python.org/issue27660 opened by xiang.zhang #27662: Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_Ne http://bugs.python.org/issue27662 opened by xiang.zhang #27664: Allow specifying prefix for thread name in concurrent.futures. http://bugs.python.org/issue27664 opened by durin42 #27665: Make create_server able to listen on several ports http://bugs.python.org/issue27665 opened by bayandin #27666: "stack smashing detected" in PyCursesWindow_Box http://bugs.python.org/issue27666 opened by Steve Fink #27671: FAQ: len() is still function for good reason. http://bugs.python.org/issue27671 opened by methane #27674: Quote mark breaks cookie processing http://bugs.python.org/issue27674 opened by Artur SmÄt #27675: IDLE file completion has 2 bugs depending on open quote used http://bugs.python.org/issue27675 opened by egerosa #27679: set_bitfields() unused in _ctypes_test http://bugs.python.org/issue27679 opened by martin.panter #27680: Reduce Github pull request rate http://bugs.python.org/issue27680 opened by holdenweb #27681: readline: consecutive rl_kill_word do not append http://bugs.python.org/issue27681 opened by qsantos #27682: Windows Error 10053, ConnectionAbortedError: [WinError 10053] http://bugs.python.org/issue27682 opened by SG #27683: ipaddress subnet slicing iterator malfunction http://bugs.python.org/issue27683 opened by tklausmann #27687: Linux shutil.move between mountpoints as root does not retain http://bugs.python.org/issue27687 opened by jort.bloem #27688: Expand documentation about Any in the typing module http://bugs.python.org/issue27688 opened by michael0x2a #27689: Add documentation for typing.Generator http://bugs.python.org/issue27689 opened by michael0x2a #27691: X509 cert with GEN_RID subject alt name causes SytemError http://bugs.python.org/issue27691 opened by christian.heimes #27692: Clean serveral unnecessary NULL checks in exceptions.c http://bugs.python.org/issue27692 opened by xiang.zhang #27693: curses.textpad.Textbox(win).edit() won't edit last character http://bugs.python.org/issue27693 opened by Dietmar Schindler Most recent 15 issues with no replies (15) == #27693: curses.textpad.Textbox(win).edit() won't edit last character http://bugs.python.org/issue27693 #27691: X509 cert with GEN_RID subject alt name causes SytemError http://bugs.python.org/issue27691 #27689: Add documentation for typing.Generator http://bugs.python.org/issue27689 #27688: Expand documentation about Any in the typing module http://bugs.python.org/issue27688 #27687: Linux shutil.move between mountpoints as root does not retain http://bugs.python.org/issue27687 #27679: set_bitfields() unused in _ctypes_test http://bugs.python.org/issue27679 #27671: FAQ: len() is still function for good reason. http://bugs.python.org/issue27671 #27666: "stack smashing detected" in PyCursesWindow_Box http://bugs.python.org/issue27666 #27664: Allow specifying prefix for thread name in concurrent.futures. http://bugs.python.org/issue27664 #27654: [Patch] Use arc4random_buf() on CloudABI http://bugs.python.org/issue27654 #27653: [Patch] Also disable the use of on CloudABI http://bugs.python.org/issue27653 #27646: yield from expression can be any iterable http://bugs.python.org/issue27646 #27636: Refactor IDLE htest http://bugs.python.org/issue27636 #27635: pickle documentation says that unpickling may not call __new__ http://bugs.python.org/issue27635 #27599: Buffer overrun in binascii http://bugs.python.org/issue27599 Most recent 15 issues waiting for review (15) = #27692: Clean serveral unnecessary NULL checks in exceptions.c http://bugs.python.org/issue27692 #
Re: [Python-Dev] C99
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 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 : > > We should definitely keep supporting MSVC. > > > > --Guido (mobile) > > > > On Jun 7, 2016 12:39 PM, "Sturla Molden" > wrote: > >> > >> Victor Stinner 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 > >> [email protected] > >> https://mail.python.org/mailman/listinfo/python-dev > >> Unsubscribe: > >> https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > ___ > > Python-Dev mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
That sounds fine to me, but we need to list specific compiler versions. On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon 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 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 : >> > We should definitely keep supporting MSVC. >> > >> > --Guido (mobile) >> > >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" >> > wrote: >> >> >> >> Victor Stinner 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 >> >> [email protected] >> >> https://mail.python.org/mailman/listinfo/python-dev >> >> Unsubscribe: >> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > >> > >> > ___ >> > Python-Dev mailing list >> > [email protected] >> > https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > >> > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com >> > >> ___ >> Python-Dev mailing list >> [email protected] >> 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) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
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 wrote: > > > On Fri, 5 Aug 2016 at 15:07 Guido van Rossum 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 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 >> > 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 : >> >> > We should definitely keep supporting MSVC. >> >> > >> >> > --Guido (mobile) >> >> > >> >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" >> >> > wrote: >> >> >> >> >> >> Victor Stinner 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 >> >> >> [email protected] >> >> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> Unsubscribe: >> >> >> >> >> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> > >> >> > >> >> > ___ >> >> > Python-Dev mailing list >> >> > [email protected] >> >> > https://mail.python.org/mailman/listinfo/python-dev >> >> > Unsubscribe: >> >> > >> >> > >> >> > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com >> >> > >> >> ___ >> >> Python-Dev mailing list >> >> [email protected] >> >> 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) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum 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 wrote: > > > > > > On Fri, 5 Aug 2016 at 15:07 Guido van Rossum > 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 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 > >> > 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 : > >> >> > We should definitely keep supporting MSVC. > >> >> > > >> >> > --Guido (mobile) > >> >> > > >> >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" > >> >> > wrote: > >> >> >> > >> >> >> Victor Stinner 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 > >> >> >> [email protected] > >> >> >> https://mail.python.org/mailman/listinfo/python-dev > >> >> >> Unsubscribe: > >> >> >> > >> >> >> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> >> > > >> >> > > >> >> > ___ > >> >> > Python-Dev mailing list > >> >> > [email protected] > >> >> > https://mail.python.org/mailman/listinfo/python-dev > >> >> > Unsubscribe: > >> >> > > >> >> > > >> >> > > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > >> >> > > >> >> ___ > >> >> Python-Dev mailing list > >> >> [email protected] > >> >> 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) > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
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 wrote: > > > On Fri, 5 Aug 2016 at 15:17 Guido van Rossum 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 wrote: >> > >> > >> > On Fri, 5 Aug 2016 at 15:07 Guido van Rossum >> > 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 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 >> >> > 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 : >> >> >> > We should definitely keep supporting MSVC. >> >> >> > >> >> >> > --Guido (mobile) >> >> >> > >> >> >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" >> >> >> > wrote: >> >> >> >> >> >> >> >> Victor Stinner 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 >> >> >> >> [email protected] >> >> >> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> Unsubscribe: >> >> >> >> >> >> >> >> >> >> >> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >> > >> >> >> > >> >> >> > ___ >> >> >> > Python-Dev mailing list >> >> >> > [email protected] >> >> >> > https://mail.python.org/mailman/listinfo/python-dev >> >> >> > Unsubscribe: >> >> >> > >> >> >> > >> >> >> > >> >> >> > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com >> >> >> > >> >> >> ___ >> >> >> Python-Dev mailing list >> >> >> [email protected] >> >> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> Unsubscribe: >> >> >> >> >> >> https://mail.python.org/mailman/options/pyth
Re: [Python-Dev] C99
On Fri, 5 Aug 2016 at 15:07 Guido van Rossum 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 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 > 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 : > >> > We should definitely keep supporting MSVC. > >> > > >> > --Guido (mobile) > >> > > >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" > >> > wrote: > >> >> > >> >> Victor Stinner 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 > >> >> [email protected] > >> >> https://mail.python.org/mailman/listinfo/python-dev > >> >> Unsubscribe: > >> >> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> > > >> > > >> > ___ > >> > Python-Dev mailing list > >> > [email protected] > >> > https://mail.python.org/mailman/listinfo/python-dev > >> > Unsubscribe: > >> > > >> > > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > >> > > >> ___ > >> Python-Dev mailing list > >> [email protected] > >> 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) > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
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" Sent: 8/5/2016 15:44 To: "Guido van Rossum" Cc: "Python-Dev" ; "Sturla Molden" Subject: Re: [Python-Dev] C99 On Fri, 5 Aug 2016 at 15:07 Guido van Rossum 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 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 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 : >> > We should definitely keep supporting MSVC. >> > >> > --Guido (mobile) >> > >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" >> > wrote: >> >> >> >> Victor Stinner 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 >> >> [email protected] >> >> https://mail.python.org/mailman/listinfo/python-dev >> >> Unsubscribe: >> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > >> > >> > ___ >> > Python-Dev mailing list >> > [email protected] >> > https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > >> > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com >> > >> ___ >> Python-Dev mailing list >> [email protected] >> 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)___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
On 6 August 2016 at 12:15, Steve Dower 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
On Aug 5, 2016, at 23:02, Nick Coghlan 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 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 wrote: >> On Fri, 5 Aug 2016 at 15:17 Guido van Rossum 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). 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 suppo
Re: [Python-Dev] C99
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 wrote: > On Aug 5, 2016, at 23:02, Nick Coghlan 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 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 wrote: >>> On Fri, 5 Aug 2016 at 15:17 Guido van Rossum 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). > > 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
Re: [Python-Dev] C99
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 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 wrote:
>> On Aug 5, 2016, at 23:02, Nick Coghlan 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 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 wrote:
On Fri, 5 Aug 2016 at 15:17 Guido van Rossum 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).
>>
>> 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
