I want it to list specific versions that are known to be good right
now, so we can point fingers appropriately when a regression happens.
OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are the latest releases (unless I'm missing a compiler we all feel like we should officially support).
If you have to ask Steve what version he used, ask!
I know of what compiler has been used by Steve, I was just trying to give a very loose example of how it could be phrased if we wanted a shifting window of support based on what was available at the time of release for Python instead of the "what was available Aug 2016" static specification that you said you wanted.
On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon <brett@python.org> wrote:
>
>
> On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanrossum@gmail.com> wrote:
>>
>> That sounds fine to me, but we need to list specific compiler versions.
>
>
> Would you want this to be static (e.g. MSVC 2016 until we choose to update
> to support C11), or would you want it to vary based on what's available when
> the current/last Python is/was released (e.g. whatever version of MSVC Steve
> uses to build the binaries for 3.5 or 3.6 in our current case)?
>
>>
>>
>> On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon <brett@python.org> wrote:
>> > Where did we finally land on this discussion? Do we want to update PEP 7
>> > to
>> > say that starting in 3.6 we may use C99 features common to all supported
>> > compilers and list what those compilers are (i.e. gcc, clang, and MSVC)?
>> >
>> > On Wed, 8 Jun 2016 at 01:28 Victor Stinner <victor.stinner@gmail.com>
>> > wrote:
>> >>
>> >> I guess that as usual, we should use the "common denominator" of all
>> >> compilers supported by CPython. For example, if MSVC doesn't support a
>> >> feature, we should not use it in CPython.
>> >>
>> >> In practice, it's easy to check if a feature is supported or not: we
>> >> have buildbots building Python at each commit. It was very common to
>> >> get a compilation error only on MSVC when a variable was defined in
>> >> the middle of a function. We are now using
>> >> -Werror=declaration-after-statement with GCC because of MSVC!
>> >>
>> >> Maybe GCC has an option to ask for the subset of the C99 standard
>> >> compatible with MSVC? Something like "-std=c99 -pedantic"?
>> >>
>> >> Note: I tried -pedantic, GCC emits a lot of warnings on code which
>> >> looks valid and/or is protected with #ifdef for features specific to
>> >> GCC like computed goto.
>> >>
>> >> Victor
>> >>
>> >> 2016-06-07 21:45 GMT+02:00 Guido van Rossum <gvanrossum@gmail.com>:
>> >> > We should definitely keep supporting MSVC.
>> >> >
>> >> > --Guido (mobile)
>> >> >
>> >> > On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.molden@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Victor Stinner <victor.stinner@gmail.com> wrote:
>> >> >>
>> >> >> > Is it worth to support a compiler that in 2016 doesn't support the
>> >> >> > C
>> >> >> > standard released in 1999, 17 years ago?
>> >> >>
>> >> >> MSVC only supports C99 when its needed for C++11 or some MS
>> >> >> extension
>> >> >> to
>> >> >> C.
>> >> >>
>> >> >> Is it worth supporting MSVC? If not, we have Intel C, Clang and
>> >> >> Cygwin
>> >> >> GCC
>> >> >> are the viable options we have on Windows (and perhaps Embarcadero,
>> >> >> but
>> >> >> I
>> >> >> haven't used C++ builder for a very long time). Even MinGW does not
>> >> >> fully
>> >> >> support C99, because it depends on Microsoft's CRT. If we think MSVC
>> >> >> and
>> >> >> MinGW are worth supporting, we cannot just use C99 indiscriminantly.
>> >> >>
>> >> >> _______________________________________________
>> >> >> Python-Dev mailing list
>> >> >> Python-Dev@python.org
>> >> >> https://mail.python.org/mailman/listinfo/python-dev
>> >> >> Unsubscribe:
>> >> >>
>> >> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Python-Dev mailing list
>> >> > Python-Dev@python.org
>> >> > https://mail.python.org/mailman/listinfo/python-dev
>> >> > Unsubscribe:
>> >> >
>> >> >
>> >> > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>> >> >
>> >> _______________________________________________
>> >> Python-Dev mailing list
>> >> Python-Dev@python.org
>> >> https://mail.python.org/mailman/listinfo/python-dev
>> >> Unsubscribe:
>> >> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
--
--Guido van Rossum (python.org/~guido)