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 <[email protected]> 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 <[email protected]> wrote:
>> On Aug 5, 2016, at 23:02, Nick Coghlan <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>>> On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <[email protected]> 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
>> [email protected] -- []
>>
>> _______________________________________________
>> 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
>
>
>
> --
> --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/songofacandy%40gmail.com
--
INADA Naoki <[email protected]>
_______________________________________________
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
