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 <n...@python.org> wrote: > On Aug 5, 2016, at 23:02, Nick Coghlan <ncogh...@gmail.com> wrote: >> As a pragmatic requirement, what if we went with: >> >> - must compile with the Python 3.5 Windows compiler (so MSVC 14.0) >> - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) >> - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513) >> >> The reason I like the pragmatic definition is that it's one we can >> readily automate by ensuring these 3 configurations are always present >> in the stable buildbot fleet, while the formal standards based version >> is technically more precise, but not in a way we can easily test. >> >> It also gives us an objective criterion for when we change the >> definitions: when the baseline compiler version for the respective >> platform builds change, and Python 3.x versions using the older >> definition are no longer supported by python-dev. >> >> Phrasing the policy that way would mean moving future iterations of >> the manylinux spec out of distutils-sig only territory into one which >> needs to be reviewed by both distutils-sig and python-dev (since it >> would now also modify CPython's compiler compatibility requirements in >> PEP 7), but I think that's a reasonable position to adopt, and >> unlikely to cause any major problems (manylinux is a *trailing* edge >> definition that is only likely to get updated as the oldest enterprise >> Linux definitions drop out of commercial support) >> >> The other question we need to consider is the possible impact on PEP >> 11: what happens to support for alternate compilers and platforms that >> *have* a buildbot, but may not support particular C99 features? Should >> there be a 4th clause that says "- must compile and run on all stable >> buildbots"? > > [Nick's reply above arrived just as I was getting ready to send my own > response below which covers some of the same territory.] > > On Aug 5, 2016, at 18:37, Guido van Rossum <gvanros...@gmail.com> wrote: >> I think if we want to revisit this in the future it should be an >> explicit change. >> On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon <br...@python.org> wrote: >>> On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanros...@gmail.com> wrote: >>>> I want it to list specific versions that are known to be good right >>>> now, so we can point fingers appropriately when a regression happens. >>> OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are >>> the latest releases (unless I'm missing a compiler we all feel like we >>> should officially support). > > While in principle allowing C99 features to be used in cpython is a *good* > thing, I'm sure that I don't fully understand all of the implications of > adopting this policy for 3.6. I think we need to be sure we don't > inadvertently drop support for some platforms and/or older releases of some > platforms. The key word is "inadvertently". Not all of those compiler > versions above are supported everywhere we currently run. If that's what we > want to do, that's fine but we should be explicit about that. Two sets of > concerns that come to mind are our buildbots and support for older OS X > releases. > > If I gathered the data correctly, for the default branch (upcoming 3.6 > release), we currently have 31 buildbots: 19 classified as "stable" and 12 as > "unstable". Of the stable buildbots, here is the count, version, and > platform architecture of compilers in use: > > 2 x MSVC 14.0 2015 64 bit (AMD64) > 1 x MSVC 14.0 2015 32 bit (AMD64) > > 1 x Clang 3.8.0 (AMD64) > 1 x Clang 3.4.1 (AMD64) > > 1 x GCC 5.3.1 (s390x) > 2 x GCC 4.9.3 (x86) > 2 x GCC 4.9.2 (AMD64) > 1 x GCC 4.9.2 (PPC64LE) > 2 x GCC 4.8.5 (s390x) > 1 x GCC 4.8.4 (x86) > 1 x GCC 4.8.3 (PPC64) > 1 x GCC 4.3.3 (AMD64) > 2 x GCC 4.2.1 (AMD64) > 1 x GCC 4.0.1 (x86) > > I know very little about the details of C99 support in those compilers but I > gather from this link (https://gcc.gnu.org/c99status.html) that GCC 4.5 is > potentially the earliest level that properly supports C99. Note that we have > a number of buildbots running version of GCC older than 4.5 (including all of > our OS X stable buildbots) and only one (an s390) running 5.x and none yet > running 6.x. > > I don't know that we've written this policy anywhere but I think it has been > our de facto policy to require only the "standard" platform build tools > (including compilers) to build or install Python on our supported platform > versions. With my OS X hat on, I know this likely presents an issue for the > OS X installer builds. Up to now, we have been providing installers that run > on all Macs that are supported back to at least OS X 10.6 and, to do that, we > build on 10.6 with the standard Apple build tools available there including > GCC 4.2. If GCC 4.2 proves to no longer be suitable, we'll have to make some > adjustment in either what versions of OS X we support and/or how we build > python.org Pythons for OS X. There are several possibilities, and, at some > point, we will need to do something anyway. I am hoping to propose and > implement some changes prior to 3.6.0b1 and this discussion will shape that > proposal. > > I don't think OS X support should be a gating factor in deciding to move > ahead with C99 adoption but it does point out that there might be more > ramifications to this decision. What may be more difficult is to judge the > impact on other platforms that don't get as much attention from most of us. > For this to move forward, we need to be able to state what the impact to > current users will be. > > -- > Ned Deily > n...@python.org -- [] > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
