Re: [Python-Dev] C99

[Nathaniel Smith]

On Sat, Oct 8, 2016 at 9:23 AM, Steven D'Aprano  wrote:
> On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote:
>
>> The reason this matters is that the official vendor compiler on RHEL 5
>> is gcc 4.1, but there's also a separately-distributed version of gcc
>> 4.8.2 that can target it.
>
> Where can I get that 4.8 for RHEL 5?
>
> I'm using Centos 5, which ought to be the same as RHEL 5, and the
> standard gcc is 4.1, with 4.4 available through yum. If 4.8 is available
> anywhere, I haven't been able to find it. And as far as I can see, 3.6
> won't build under either 4.1 or 4.4 on Centos 5.

It's RH's "devtoolset" release. The build scripts for the manylinux
docker images demonstrate how to install them:

https://github.com/pypa/manylinux/blob/master/docker/build_scripts/build.sh#L38

(Unfortunately this involves installing them from a random CentOS
dev's home directory over plain-HTTP, but that's the only way to get
them if you don't have the appropriate RHEL subscription -- see
https://github.com/pypa/manylinux/issues/46#issuecomment-205054077)

>> If a packager trying to build manylinux
>> wheels wants a more modern gcc, then it's reasonable to ask them to
>> get this patched gcc. But for an end-user who's just trying to build
>> CPython on their machine, you might or might not consider this an
>> acceptable request -- maybe CPython wants to work on default vendor
>> compiler to imposing that on users.
>>
>> And in practice this almost certainly doesn't matter -- the only
>> reason people jump through hoops to get gcc 4.8 is for its improved
>> C++ support. I just tried my c99 test file on CentOS 5's default gcc
>> 4.1 and it was fine.
>
> Can you try building Python 3.6? Because it fails for me, and the
> discussion here:
>
> http://bugs.python.org/issue28092
>
> concluded that 4.1 is not supported and I'm right out of luck until I
> can upgrade.

I don't have time to follow up right now, but something like

  docker run -v $PWD:/io -it --rm quay.io/pypa/manylinux1_x86_64 /bin/bash

should drop you into a shell in a temporary centos5 VM where 'gcc' is 4.8.2.

>From the bug report it sounds like the issue is that my comments above
about 'we only care about static inline' were wrong, or at least,
Benjamin disagrees :-). I guess the revised version is
- if we insist on full C99 inline support, then that means dropping
support for building with vendor gcc on CentOS 5 and OS X (and
possibly dropping support for older OS X altogether?)
- if we are willing to restrict ourselves to 'static inline' and forgo
the other 'inline' variants, then all the other C99 things we care
about are fine and we can keep support for vendor gcc on CentOS 5 and
OS X.

-n

-- 
Nathaniel J. Smith -- https://vorpus.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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Steven D'Aprano]

On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote:

> The reason this matters is that the official vendor compiler on RHEL 5
> is gcc 4.1, but there's also a separately-distributed version of gcc
> 4.8.2 that can target it. 

Where can I get that 4.8 for RHEL 5?

I'm using Centos 5, which ought to be the same as RHEL 5, and the 
standard gcc is 4.1, with 4.4 available through yum. If 4.8 is available 
anywhere, I haven't been able to find it. And as far as I can see, 3.6 
won't build under either 4.1 or 4.4 on Centos 5.


> If a packager trying to build manylinux
> wheels wants a more modern gcc, then it's reasonable to ask them to
> get this patched gcc. But for an end-user who's just trying to build
> CPython on their machine, you might or might not consider this an
> acceptable request -- maybe CPython wants to work on default vendor
> compiler to imposing that on users.
> 
> And in practice this almost certainly doesn't matter -- the only
> reason people jump through hoops to get gcc 4.8 is for its improved
> C++ support. I just tried my c99 test file on CentOS 5's default gcc
> 4.1 and it was fine. 

Can you try building Python 3.6? Because it fails for me, and the 
discussion here:

http://bugs.python.org/issue28092

concluded that 4.1 is not supported and I'm right out of luck until I 
can upgrade.




-- 
Steve
___
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

Re: [Python-Dev] C99

[Nathaniel Smith]

On Thu, Oct 6, 2016 at 10:10 PM, Nathaniel Smith  wrote:
[...]
> And in practice this almost certainly doesn't matter -- the only
> reason people jump through hoops to get gcc 4.8 is for its improved
> C++ support. I just tried my c99 test file on CentOS 5's default gcc
> 4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for
> 3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4,
> which is even less of a worry.
>
> tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4"
> should be a fine rule that works for everyone. But I guess we probably
> also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.

Doh, I have an off-by-one error, and wrote 3.5/3.6 where I meant 3.6/3.7.

If the change is on the table for 3.6, then I guess I'd suggest
continuing to support gcc 4.1 through the 3.6 support lifecycle, since
I believe CentOS/RHEL 5 are considered supported platforms for 3.6,
and the burden of doing this is probably very small. In particular, it
doesn't seem to block any C99 features that we care about.

(Is the list of supported platforms for Linux documented anywhere? PEP
11 documents the rule for Windows, and I'm assuming that the same rule
applies to RHEL.)

-n

-- 
Nathaniel J. Smith -- https://vorpus.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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Nathaniel Smith]

On Fri, Aug 5, 2016 at 8:02 PM, Nick Coghlan  wrote:
> 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.

This approach makes a lot of sense to me. In particular it seems like
it can avoid getting bogged down in a lot of questions about the
theoretical idea of C99, which is often somewhat unclear.

I wrote a little test file for all the C99 features that were
mentioned in this thread (I think):
  https://gist.github.com/njsmith/f71de31f35644bb91a815c9cad75

Ned reports that our OS X compiler is currently GCC 4.2, and that this
doesn't officially support "C99" -- but I just checked and it happily
builds that file :-). (Judging from [1], it looks like the major
feature missing in 4.2 was support for C99's more obscure inlining
semantics; but I think we only really care about 'static inline'
specifically, and that appears to be unchanged [2].)

> 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)

With my manylinux maintainer hat on, I don't think there'd be any
problem with bringing python-dev into those discussions.

But note that technically, the manylinux1 spec doesn't say what
compiler you can use; it says that whatever compiler you use has to
generate binaries that work on CentOS 5. (Why CentOS 5? Because it's
the oldest non-EOL linux distribution in common use; manylinux2 will
presumably bump the requirement to CentOS 6 once CentOS 5 goes EOL).

The reason this matters is that the official vendor compiler on RHEL 5
is gcc 4.1, but there's also a separately-distributed version of gcc
4.8.2 that can target it. If a packager trying to build manylinux
wheels wants a more modern gcc, then it's reasonable to ask them to
get this patched gcc. But for an end-user who's just trying to build
CPython on their machine, you might or might not consider this an
acceptable request -- maybe CPython wants to work on default vendor
compiler to imposing that on users.

And in practice this almost certainly doesn't matter -- the only
reason people jump through hoops to get gcc 4.8 is for its improved
C++ support. I just tried my c99 test file on CentOS 5's default gcc
4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for
3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4,
which is even less of a worry.

tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4"
should be a fine rule that works for everyone. But I guess we probably
also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.

-n

[1] https://gcc.gnu.org/c99status.html
[2] "The [different versions] of inlining behave similarly ... when
the inline keyword is used on a static function" --
https://gcc.gnu.org/onlinedocs/gcc/Inline.html

-- 
Nathaniel J. Smith -- https://vorpus.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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Michael Felt]

On 04-Jun-16 10:12, Sebastian Krause wrote:

Sounds good for features that are well-supported by compilers that
>people use. (Are there other compilers used than just GCC and MSVC?)
Just thought I'd mention that "little ole me" is using IBM vac on AIX 
rather than gcc.
This has more to do with maintaining the gcc rte requirements of 
anything built by gcc rather compiler features.


There is one gcc compiler feature that has proved a show-stopper - 
constructor - in glibc (Gnome). There they also make an exception for 
Windows, but not for "other" compilers.


FYI: calling the IBM C compiler as c99 magically makes it c99 compliant, 
as xlc makes it c99 plus several extensions - and take note - as cc it 
is "pre-c89". In other words, calling IBM compiler as "cc" is not a wise 
thing to do - I recommend to anyone listing to use either "xlc" or "xlc_r".


Michael
___
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

Re: [Python-Dev] C99

[Stephen J. Turnbull]

Ned Deily writes:

 > But the point I was trying to make is that, by changing the
 > language requirement, we will likely have an effect on what
 > platforms (across the board) and versions we support and we should
 > take that into account when making this decision.  It may be the
 > right decision, in balance, to drop support for some of these but
 > we shouldn't do it by accident.

Sure, you were clear enough about that.  My point was simply that at
least for older Macs it probably is not that big a problem (but I do
have a Panther still running, at least as of March it did ;-).

Similarly, for platforms where we build with GCC, many of these
features have been available for a long time with switches.

Adding it all up, we don't want to break anybody inadvertantly and we
should take care to fix what breakage we can in advance, but I think
it's time to allow at least some of these features, and maybe move to
C99 wholesale.

Steve
___
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

Re: [Python-Dev] C99

[INADA Naoki]

>>
>> * inline function
>> static inline function can be used instead of may macros.
>> It is more readable, and type safe.
>
> My experience from a few months ago with some cross-platform code is
> that clang, GCC and MSVC have different ideas about how inline
> functions in C work. Are they static or extern? Do you need provide an
> implementation body somewhere?

You're right. I think inline function should be used as "static inline" always.

Python uses "static inline" already, via "Py_LOCAL_INLINE" macro, when
USE_INLINE is defined. So using "static inline" is not problem.

If we can assume inline is usable, we can remove the macro, and use
"static inline"
more often to replace macros.
___
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

Re: [Python-Dev] C99

[Hugh Fisher]

> Message: 2
> Date: Sat, 6 Aug 2016 14:27:15 +0900
> From: INADA Naoki <songofaca...@gmail.com>
> To: Guido van Rossum <gu...@python.org>
> Cc: Ned Deily <n...@python.org>, Python-Dev <python-dev@python.org>
> Subject: Re: [Python-Dev] C99
> Message-ID:
> <CAEfz+Twc9t2pO4zzO3yyfvAPN0aWWV99YnvSjuPSq1=v3lk...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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.

My experience from a few months ago with some cross-platform code is
that clang, GCC and MSVC have different ideas about how inline
functions in C work. Are they static or extern? Do you need provide an
implementation body somewhere?

There are also differences between the C++ and C99 definitions.

Probably all solvable with build settings, but not as easy as one line comments.

-- 

cheers,
Hugh Fisher
___
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

Re: [Python-Dev] C99

[Sturla Molden]

Guido van Rossum  wrote:

> This feels close to a code of conduct violation. This kind of language
> may be okay on the Linux kernel list, but I don't see the point of it
> here.

Sorry, I should have found a more diplomatic formulation. But the principle
remains, build problems araising from missing Xcode installation should not
be CPython's problem. It is ok to assume that Xcode is always installed
when CPython is built on OSX.

___
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

Re: [Python-Dev] C99

[Alexander Belopolsky]

On Sat, Aug 6, 2016 at 5:55 PM, Sturla Molden  wrote:
> Either they install Xcode or they
> don't get to build anything.

I always thought "Command Line Tools" would be enough.

https://developer.apple.com/library/ios/technotes/tn2339/_index.html#//apple_ref/doc/uid/DTS40014588-CH1-WHAT_IS_THE_COMMAND_LINE_TOOLS_PACKAGE_
___
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

Re: [Python-Dev] C99

[Guido van Rossum]

On Sat, Aug 6, 2016 at 2:55 PM, Sturla Molden  wrote:
> Xcode must be installed to build anything on Mac. It is not optional. Users
> who need to build Python without installing Xcode need to fix their heads.
> Because that is where their problem resides. There is no remedy for
> stubbornness to the level of stupidity. Either they install Xcode or they
> don't get to build anything.

This feels close to a code of conduct violation. This kind of language
may be okay on the Linux kernel list, but I don't see the point of it
here.

-- 
--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

Re: [Python-Dev] C99

[Ned Deily]

On Aug 6, 2016, at 17:55, Sturla Molden  wrote:
> On OSX 10.8 and earlier, the default CC is llvm-gcc-4.2.1, available as the
> gcc command. clang is also installed, so we can always 
[...]

Thanks, but this is getting way off-topic.  I am well aware of what compilers 
are available on what releases and how to use them.  That's not the issue under 
discussion here.

--
  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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Sturla Molden]

"Stephen J. Turnbull"  wrote:

> I may be talking through my hat here, but Apple has been using LLVM
> for several major releases now.  They seem to be keeping the GCC
> frontend stuck at 4.2.1, though.  So just because we've been using GCC
> 4.2.1 on Mac, including on buildbots, doesn't mean that there is no
> C99 compiler available on Macs -- it's quite possible that the
> available clang frontend does already support the C99 features we
> would use.  I suppose that might mean fiddling with the installer
> build process as well as the buildbots.

On OSX 10.8 and earlier, the default CC is llvm-gcc-4.2.1, available as the
gcc command. clang is also installed, so we can always 

$ export CC=clang
$ export CXX=clang++

to remedy the problem.

On OSX 10.9 and later, gcc is just a symlink to clang.

Xcode must be installed to build anything on Mac. It is not optional. Users
who need to build Python without installing Xcode need to fix their heads.
Because that is where their problem resides. There is no remedy for
stubbornness to the level of stupidity. Either they install Xcode or they
don't get to build anything. 


Sturla

___
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

Re: [Python-Dev] C99

[Sturla Molden]

Ned Deily  wrote:

> On Aug 6, 2016, at 01:16, Stephen J. Turnbull 
>  wrote:
>> I may be talking through my hat here, but Apple has been using LLVM
>> for several major releases now.  They seem to be keeping the GCC
>> frontend stuck at 4.2.1, though.  So just because we've been using GCC
>> 4.2.1 on Mac, including on buildbots, doesn't mean that there is no
>> C99 compiler available on Macs -- it's quite possible that the
>> available clang frontend does already support the C99 features we
>> would use.  I suppose that might mean fiddling with the installer
>> build process as well as the buildbots.
> 
> Sorry, I wasn't clear; I did not mean to imply there is no C99 compiler
> available from Apple for OS X.  On current OS X releases, clang is the
> default and only supported compiler.  I was bringing up the example of
> the impact on building on older releases with the supported build tools
> for those releases where clang is either not available or was too
> immature to be usable.  As I said, there are a number of solutions to
> that problem - building on newer systems with deployment targets,
> installing third-party compilers, etc.



Clang is also available (and installed) on OSX 10.8 and earlier, although
gcc 4.2.1 is the default frontend to LLVM. The easiest solution to get C99
on those platforms is

$ export CC=clang

Not very difficult, and highly recommended.



Sturla Molden

___
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

Re: [Python-Dev] C99

[Brett Cannon]

On Sat, 6 Aug 2016 at 10:16 Ned Deily  wrote:

> On Aug 6, 2016, at 00:04, 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.
>
> I'm certainly not, either.  Looking back over the original thread, there
> were a number of features talked about.  I think Larry's list here captures
> most of them:
>
> "Clearly it'll be 3.5+ only, and clearly it'll be a specific list of
> features ("C89 but also permitting //-comments, variadic macros,
> variable declarations on any line, inline functions, and designated
> initializers").  But I'm looking forward to it!"
>
> https://mail.python.org/pipermail/python-dev/2016-June/144831.html
>
> So, if that set of features seems reasonable, perhaps the next step is for
> someone (not me) to put together a test patch that incorporates the use of
> them and then we can run it against the buildbots, either by using the
> special build buildbots or just temporarily checking the patch in.  I'm
> willing to do the testing and results-gathering if a patch is supplied.
>

If you want to take that route then you could try temporarily patching one
of the xx* modules as an example.
___
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

Re: [Python-Dev] C99

[Ned Deily]

On Aug 6, 2016, at 00:04, 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.

I'm certainly not, either.  Looking back over the original thread, there were a 
number of features talked about.  I think Larry's list here captures most of 
them:

"Clearly it'll be 3.5+ only, and clearly it'll be a specific list of 
features ("C89 but also permitting //-comments, variadic macros, 
variable declarations on any line, inline functions, and designated 
initializers").  But I'm looking forward to it!"

https://mail.python.org/pipermail/python-dev/2016-June/144831.html

So, if that set of features seems reasonable, perhaps the next step is for 
someone (not me) to put together a test patch that incorporates the use of them 
and then we can run it against the buildbots, either by using the special build 
buildbots or just temporarily checking the patch in.  I'm willing to do the 
testing and results-gathering if a patch is supplied.

--
  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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Ned Deily]

On Aug 6, 2016, at 01:16, Stephen J. Turnbull 
 wrote:
> I may be talking through my hat here, but Apple has been using LLVM
> for several major releases now.  They seem to be keeping the GCC
> frontend stuck at 4.2.1, though.  So just because we've been using GCC
> 4.2.1 on Mac, including on buildbots, doesn't mean that there is no
> C99 compiler available on Macs -- it's quite possible that the
> available clang frontend does already support the C99 features we
> would use.  I suppose that might mean fiddling with the installer
> build process as well as the buildbots.

Sorry, I wasn't clear; I did not mean to imply there is no C99 compiler 
available from Apple for OS X.  On current OS X releases, clang is the default 
and only supported compiler.  I was bringing up the example of the impact on 
building on older releases with the supported build tools for those releases 
where clang is either not available or was too immature to be usable.  As I 
said, there are a number of solutions to that problem - building on newer 
systems with deployment targets, installing third-party compilers, etc.

But the point I was trying to make is that, by changing the language 
requirement, we will likely have an effect on what platforms (across the board) 
and versions we support and we should take that into account when making this 
decision.  It may be the right decision, in balance, to drop support for some 
of these but we shouldn't do it by accident.

--
  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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Stephen J. Turnbull]

Ned Deily writes:

 > 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.

I may be talking through my hat here, but Apple has been using LLVM
for several major releases now.  They seem to be keeping the GCC
frontend stuck at 4.2.1, though.  So just because we've been using GCC
4.2.1 on Mac, including on buildbots, doesn't mean that there is no
C99 compiler available on Macs -- it's quite possible that the
available clang frontend does already support the C99 features we
would use.  I suppose that might mean fiddling with the installer
build process as well as the buildbots.

Also, it seems like it's been a decade since a C compiler came
standard with Mac OS X -- you need to download and install Xcode or
at least xcodebuildtools separately.  So unless the Macs are quite
ancient (fvo ancient = 5 years old), at least at one time they were
upgradeable by installing Xcode.

Of course Mac users may not be willing or able to upgrade Xcode, but
at least the possibility is worth investigating.

 > 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.

We could post a poll to python-list (to be hosted on surveymonkey or
similar, *not* back to this list!), explaining the proposal and asking
"what is your platform?", "what compiler and version do you use?",
"does it support C99 (perhaps with switches)?", "if not, can you
upgrade to one with C99 support?", and "if you can upgrade, how much
pain would it be to upgrade?"

I guess the last one would take values from "I'd be annoyed for less
than 10 minutes then forget it" to "enough so that I wouldn't upgrade
Python".  I suppose one intermediate answer might be "I'd have to
maintain a separate compiler just for Python."

___
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

Re: [Python-Dev] C99

[Sturla Molden]

Matthias Klose  wrote:

> GCC 5 and GCC 6 default to C11 (-std=gnu11), does the restriction to C99 mean
> that -std=gnu99 should be passed explicitly?

Also note that -std=c99 is not the same as -std=gnu99. The latter allows
GNU extensions like computed goto. Does the interpreter depend on those?
(Presumably it could be a benefit.)

Sturla

___
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

Re: [Python-Dev] C99

[Matthias Klose]

On 06.08.2016 00:27, 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).

please make that GCC 6.2 once released later this month (6.1 is the first 6.x
release).

GCC 5 and GCC 6 default to C11 (-std=gnu11), does the restriction to C99 mean
that -std=gnu99 should be passed explicitly?

___
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

Re: [Python-Dev] C99

[INADA Naoki]

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 

Re: [Python-Dev] C99

[Guido van Rossum]

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 

Re: [Python-Dev] C99

[Ned Deily]

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 

Re: [Python-Dev] C99

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] C99

[Steve Dower]

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" <br...@python.org>
Sent: ‎8/‎5/‎2016 15:44
To: "Guido van Rossum" <gvanros...@gmail.com>
Cc: "Python-Dev" <python-dev@python.org>; "Sturla Molden" 
<sturla.mol...@gmail.com>
Subject: Re: [Python-Dev] C99




On Fri, 5 Aug 2016 at 15:07 Guido van Rossum <gvanros...@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 <br...@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.stin...@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 <gvanros...@gmail.com>:
>> > We should definitely keep supporting MSVC.
>> >
>> > --Guido (mobile)
>> >
>> > On Jun 7, 2016 12:39 PM, "Sturla Molden" <sturla.mol...@gmail.com>
>> > wrote:
>> >>
>> >> Victor Stinner <victor.stin...@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)___
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

Re: [Python-Dev] C99

[Brett Cannon]

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
> >> >> 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)
>
___
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

Re: [Python-Dev] C99

[Guido van Rossum]

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
>> >> >> >> 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
>> >> >> >
>> >> >> ___
>> >> >> 

Re: [Python-Dev] C99

[Brett Cannon]

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
> >> >> >> 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)
>
___
Python-Dev 

Re: [Python-Dev] C99

[Guido van Rossum]

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
>> >> >> 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)
___
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

Re: [Python-Dev] C99

[Guido van Rossum]

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
>> >> 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)
___
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

Re: [Python-Dev] C99

[Brett Cannon]

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
> >> 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
>
___
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

Re: [Python-Dev] C99

[Stefan Krah]

Michael Felt  felt.demon.nl> writes: 
> I am using IBM xlc aka vac - version 11.
> 
> afaik it will deal with c99 features (by default I set it to behave that 
> way because a common 'issue' is C++ style comments, when they should not 
> be that style (fyi: not seen that in Python).

We had a couple of exotic build machines a while ago: xlc, the
HPUX compiler and a couple of others all support the subset of C99
we are aiming for.  In fact the support of the commercial Unix
compilers for C99 is quite good -- the common error messages
suggest that several of them use the same front end (Comeau?).


Stefan Krah

___
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

Re: [Python-Dev] C99

[Michael Felt]

I am using IBM xlc aka vac - version 11.

afaik it will deal with c99 features (by default I set it to behave that 
way because a common 'issue' is C++ style comments, when they should not 
be that style (fyi: not seen that in Python).


IMHO: GCC is not just a compiler - it brings with it a whole set of 
infrastructure requirements (aka run-time environment, rte). Certainly 
not an issue for GNU environments, but non-gnu (e.g., posix) will/may 
have continual side-effects from "competing" rte.. At least that was my 
experience when I was using gcc rather than xlc.



On 6/4/2016 9:53 AM, Martin Panter wrote:

Sounds good for features that are well-supported by compilers that
people use. (Are there other compilers used than just GCC and MSVC?)


___
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

Re: [Python-Dev] C99

[Victor Stinner]

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
>> 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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Sturla Molden]

Nathaniel Smith  wrote:

> No-one's proposing to use C99 indiscriminately;

> There's no chance that CPython is going to drop MSVC support in 3.6.

Stinner was proposing that by saying

"Is it worth to support a compiler that in 2016 doesn't support the C
standard released in 1999, 17 years ago?"

This is basically a suggestion to drop MSVC support, as I read it. That is
never going to happen.


Sturla

___
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

Re: [Python-Dev] C99

[Nathaniel Smith]

On Tue, Jun 7, 2016 at 12:37 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.

No-one's proposing to use C99 indiscriminately; AFAICT the proposal
was: it would make a big difference if the CPython core could start
using some of C99's basic features like long long, inline functions,
and mid-block declarations, and all interesting compilers support
these, so let's officially switch from C89-only to
C89-plus-the-bits-of-C99-that-MSVC-supports. This would be a big
improvement and is just a matter of recognizing the status quo; no
need to drag in anything controversial.

There's no chance that CPython is going to drop MSVC support in 3.6.
Intel C is hardly a viable option given that the license requires the
people running the compiler to accept unbounded liability for Intel
lawyer bills and imposes non-DFSG-free conditions on the compiled
output. And Cygwin GCC isn't even real Windows. Maybe switching to
Clang will make sense in 3.7 but that's a long ways off...

-n

-- 
Nathaniel J. Smith -- https://vorpus.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/archive%40mail-archive.com

Re: [Python-Dev] C99

[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
> 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/archive%40mail-archive.com

Re: [Python-Dev] C99

[tritium-list]

Doesn't Cygwin build against the posix abstraction layer?  Wouldn't a python
built as such operate as though it was on a unix of some sort?  It has been
quite a while since I messed with Cygwin - if it hasn't changed, it's not
really an option, especially when we have native windows builds now.  It
would be too much of a downgrade in experience and performance.

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Sturla Molden
> Sent: Tuesday, June 7, 2016 3:37 PM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] C99
> 
> Victor Stinner <victor.stin...@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/tritium-
> list%40sdamon.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/archive%40mail-archive.com

Re: [Python-Dev] C99

[Sturla Molden]

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
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

Re: [Python-Dev] C99

[Guido van Rossum]

So here's the diffs that seem to indicate we were working with a compiler
that wasn't full C99 (or maybe previously we were working with a compiler
that had extensions?)

https://github.com/dropbox/typed_ast/commit/f7497e25abc3bcceced3ca6c3be3786d8805df41

On Tue, Jun 7, 2016 at 8:18 AM, Guido van Rossum  wrote:

> I'll ask my colleague what his compiler setup was.
>
> On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner 
> wrote:
>
>> Hi,
>>
>> 2016-06-04 19:47 GMT+02:00 Guido van Rossum :
>> > Funny. Just two weeks ago I was helping someone who discovered a
>> > compiler that doesn't support the new relaxed variable declaration
>> > rules. I think it was on Windows. Maybe this move is a little too
>> > aggressively deprecating older Windows compilers?
>>
>> I understood that Python only has a tiny list of officially supported
>> compilers. For example, MinGW is somehow explicitly not supported and
>> I see this as a deliberate choice.
>>
>> I'm quite sure that all supported compilers support C99.
>>
>> Is it worth to support a compiler that in 2016 doesn't support the C
>> standard released in 1999, 17 years ago?
>>
>> Victor
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--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

Re: [Python-Dev] C99

[Guido van Rossum]

I'll ask my colleague what his compiler setup was.

On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner 
wrote:

> Hi,
>
> 2016-06-04 19:47 GMT+02:00 Guido van Rossum :
> > Funny. Just two weeks ago I was helping someone who discovered a
> > compiler that doesn't support the new relaxed variable declaration
> > rules. I think it was on Windows. Maybe this move is a little too
> > aggressively deprecating older Windows compilers?
>
> I understood that Python only has a tiny list of officially supported
> compilers. For example, MinGW is somehow explicitly not supported and
> I see this as a deliberate choice.
>
> I'm quite sure that all supported compilers support C99.
>
> Is it worth to support a compiler that in 2016 doesn't support the C
> standard released in 1999, 17 years ago?
>
> Victor
>



-- 
--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

Re: [Python-Dev] C99

[Victor Stinner]

Hi,

2016-06-04 19:47 GMT+02:00 Guido van Rossum :
> Funny. Just two weeks ago I was helping someone who discovered a
> compiler that doesn't support the new relaxed variable declaration
> rules. I think it was on Windows. Maybe this move is a little too
> aggressively deprecating older Windows compilers?

I understood that Python only has a tiny list of officially supported
compilers. For example, MinGW is somehow explicitly not supported and
I see this as a deliberate choice.

I'm quite sure that all supported compilers support C99.

Is it worth to support a compiler that in 2016 doesn't support the C
standard released in 1999, 17 years ago?

Victor
___
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

Re: [Python-Dev] C99

[Terry Reedy]

On 6/6/2016 10:31 AM, Eric V. Smith wrote:


Right. So we could use C99 features in 3.6 .h files, as long as the same
extension module, unmodified, could be compiled with 3.5 .h files with a
3.5 approved (C89) compiler, and also with a 3.6 approved (C99) compiler.



The headers would be different, but so would the compilers.


On Windows, the compiler would be the 2015 MS compiler in both cases. 
Steve Dower would know if compiler flags need to be changed to enable or 
stop disabling C99 features.


> It's the

extension module source code that must be the same in the two scenarios.


We could run the experiment ourselves by changing one or more .h files 
to include one or more of the C99 features we want while leaving our .c 
files alone in the sense of remaining C89 compatible.  Compile and run 
the test suite.  If successful, add more.  We would soon find out 
whether any of the features we want in header files require use of C99 
features in .c files that include them.  With a .h standard established, 
we could then revise *our* .c files without imposing the same on 
extensions.



--
Terry Jan Reedy

___
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

Re: [Python-Dev] C99

[Guido van Rossum]

Right.

On Mon, Jun 6, 2016 at 7:31 AM, Eric V. Smith  wrote:
> On 06/06/2016 10:11 AM, Guido van Rossum wrote:
>> On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden  
>> wrote:
>>> Guido van Rossum  wrote:
>>>
 I'm not sure I meant that. But if I have a 3rd party extension that
 compiles with 3.5 headers using C89, then it should still compile with
 3.6 headers using C99. Also if I compile it for 3.5 and it only uses
 the ABI it should still be linkable with 3.6.
>>>
>>> Ok, but if third-party developers shall be free to use a C89 compiler for
>>> their own code, we cannot have C99 in the include files. Otherwise the
>>> include files will taint the C89 purity of their source code.
>>
>> Well, they should use the right compiler for the Python version they
>> are targeting. I'm just saying that they can't afford C99 features in
>> their own code. Not even to call C/Python APIs. I think it would be
>> okay if e.g. Py_INCREF was an inline function in Python 3.6, as long
>> as the way you use it remains the same.
>
> Right. So we could use C99 features in 3.6 .h files, as long as the same
> extension module, unmodified, could be compiled with 3.5 .h files with a
> 3.5 approved (C89) compiler, and also with a 3.6 approved (C99) compiler.
>
> The headers would be different, but so would the compilers. It's the
> extension module source code that must be the same in the two scenarios.
>
> We're not saying that an extension module must compile with a C89
> compiler under 3.6.
>
> Eric.
>
>
> ___
> 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

Re: [Python-Dev] C99

[Eric V. Smith]

On 06/06/2016 10:11 AM, Guido van Rossum wrote:
> On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden  wrote:
>> Guido van Rossum  wrote:
>>
>>> I'm not sure I meant that. But if I have a 3rd party extension that
>>> compiles with 3.5 headers using C89, then it should still compile with
>>> 3.6 headers using C99. Also if I compile it for 3.5 and it only uses
>>> the ABI it should still be linkable with 3.6.
>>
>> Ok, but if third-party developers shall be free to use a C89 compiler for
>> their own code, we cannot have C99 in the include files. Otherwise the
>> include files will taint the C89 purity of their source code.
> 
> Well, they should use the right compiler for the Python version they
> are targeting. I'm just saying that they can't afford C99 features in
> their own code. Not even to call C/Python APIs. I think it would be
> okay if e.g. Py_INCREF was an inline function in Python 3.6, as long
> as the way you use it remains the same.

Right. So we could use C99 features in 3.6 .h files, as long as the same
extension module, unmodified, could be compiled with 3.5 .h files with a
3.5 approved (C89) compiler, and also with a 3.6 approved (C99) compiler.

The headers would be different, but so would the compilers. It's the
extension module source code that must be the same in the two scenarios.

We're not saying that an extension module must compile with a C89
compiler under 3.6.

Eric.


___
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

Re: [Python-Dev] C99

[Guido van Rossum]

On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden  wrote:
> Guido van Rossum  wrote:
>
>> I'm not sure I meant that. But if I have a 3rd party extension that
>> compiles with 3.5 headers using C89, then it should still compile with
>> 3.6 headers using C99. Also if I compile it for 3.5 and it only uses
>> the ABI it should still be linkable with 3.6.
>
> Ok, but if third-party developers shall be free to use a C89 compiler for
> their own code, we cannot have C99 in the include files. Otherwise the
> include files will taint the C89 purity of their source code.

Well, they should use the right compiler for the Python version they
are targeting. I'm just saying that they can't afford C99 features in
their own code. Not even to call C/Python APIs. I think it would be
okay if e.g. Py_INCREF was an inline function in Python 3.6, as long
as the way you use it remains the same.

-- 
--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

Re: [Python-Dev] C99

[Guido van Rossum]

On Mon, Jun 6, 2016 at 6:25 AM, Random832  wrote:
> On Mon, Jun 6, 2016, at 07:23, Sturla Molden wrote:
>> Ok, but if third-party developers shall be free to use a C89 compiler for
>> their own code, we cannot have C99 in the include files. Otherwise the
>> include files will taint the C89 purity of their source code.
>>
>> Personally I don't think we need to worry about compilers that don't
>> implement C99 features like inline functions in C. How long have the
>> Linux
>> kernel used inline functions instead of macros? 20 years or more?
>
> Using inline functions instead of macros doesn't have to mean anything
> but a performance hit on platforms that don't support them, since the
> inline keyword, or some other identifier, could be defined to expand to
> an empty token sequence on platforms that do not support it. It's much
> lower impact on the source code than some other C99 features.

That could be a major performance impact.

-- 
--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

Re: [Python-Dev] C99

[Random832]

On Mon, Jun 6, 2016, at 07:23, Sturla Molden wrote:
> Ok, but if third-party developers shall be free to use a C89 compiler for
> their own code, we cannot have C99 in the include files. Otherwise the
> include files will taint the C89 purity of their source code.
> 
> Personally I don't think we need to worry about compilers that don't
> implement C99 features like inline functions in C. How long have the
> Linux
> kernel used inline functions instead of macros? 20 years or more?

Using inline functions instead of macros doesn't have to mean anything
but a performance hit on platforms that don't support them, since the
inline keyword, or some other identifier, could be defined to expand to
an empty token sequence on platforms that do not support it. It's much
lower impact on the source code than some other C99 features.
___
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

Re: [Python-Dev] C99

[Sturla Molden]

Guido van Rossum  wrote:

> I'm not sure I meant that. But if I have a 3rd party extension that
> compiles with 3.5 headers using C89, then it should still compile with
> 3.6 headers using C99. Also if I compile it for 3.5 and it only uses
> the ABI it should still be linkable with 3.6.

Ok, but if third-party developers shall be free to use a C89 compiler for
their own code, we cannot have C99 in the include files. Otherwise the
include files will taint the C89 purity of their source code.

Personally I don't think we need to worry about compilers that don't
implement C99 features like inline functions in C. How long have the Linux
kernel used inline functions instead of macros? 20 years or more?

Sturla

___
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

Re: [Python-Dev] C99

[Guido van Rossum]

I'm not sure I meant that. But if I have a 3rd party extension that
compiles with 3.5 headers using C89, then it should still compile with
3.6 headers using C99. Also if I compile it for 3.5 and it only uses
the ABI it should still be linkable with 3.6.

On Sun, Jun 5, 2016 at 7:42 PM, Sturla Molden  wrote:
>  wrote:
>
>> I share Guido's priority there - source compatibility is more important than
>> smoothing a few of C's rough edges.  Maybe the next breaking change release
>> this should be considered (python 4000... python 5000?)
>
> I was simply pointing out that Guido's priority removes a lot of the
> usefulness of C99 at source level. I was not saying I disagreed. If we have
> to keep header files clean of C99 I think this proposal just adds clutter.
>
> ___
> 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

Re: [Python-Dev] C99

[Émanuel Barry]

> From: Python-Dev [mailto:python-dev-
> bounces+vgr255=live...@python.org] On Behalf Of tritium-
> l...@sdamon.com
> Sent: Sunday, June 05, 2016 10:35 PM
> To: 'Sturla Molden'; python-dev@python.org
> Subject: Re: [Python-Dev] C99
> 
> > -Original Message-
> > From: Python-Dev [mailto:python-dev-bounces+tritium-
> > list=sdamon@python.org] On Behalf Of Sturla Molden
> > Sent: Sunday, June 5, 2016 10:29 PM
> > To: python-dev@python.org
> > Subject: Re: [Python-Dev] C99
> >
> > Guido van Rossum <gu...@python.org> wrote:
> >
> > > I'm talking about 3rd party extensions. Those may require source
> > > compatibility with older Python versions. All I'm asking for is to not
> > > require source-level use of C99 features.
> >
> > This of course removes a lot of its usefulness. E.g. macros cannot be
> > replaced by inline functions, as header files must still be plain C89.
> >
> >
> > Sturla Molden
> >
> 
> I share Guido's priority there - source compatibility is more important
than
> smoothing a few of C's rough edges. 

Correct me if I'm wrong, but I think that Guido meant that the third-party
extensions might require their own code (not CPython's) to be compatible
with versions of CPython < 3.6, and so PEP 7 shouldn't force them to break
their own backwards compatibility.

Either way I'm +1 for allowing (but not enforcing) C99 syntax.

> Maybe the next breaking change release
> this should be considered (python 4000... python 5000?)

Let's not!

-Emanuel
___
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

Re: [Python-Dev] C99

[Sturla Molden]

 wrote:

> I share Guido's priority there - source compatibility is more important than
> smoothing a few of C's rough edges.  Maybe the next breaking change release
> this should be considered (python 4000... python 5000?)

I was simply pointing out that Guido's priority removes a lot of the
usefulness of C99 at source level. I was not saying I disagreed. If we have
to keep header files clean of C99 I think this proposal just adds clutter.

___
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

Re: [Python-Dev] C99

[tritium-list]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Sturla Molden
> Sent: Sunday, June 5, 2016 10:29 PM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] C99
> 
> Guido van Rossum <gu...@python.org> wrote:
> 
> > I'm talking about 3rd party extensions. Those may require source
> > compatibility with older Python versions. All I'm asking for is to not
> > require source-level use of C99 features.
> 
> This of course removes a lot of its usefulness. E.g. macros cannot be
> replaced by inline functions, as header files must still be plain C89.
> 
> 
> Sturla Molden
> 

I share Guido's priority there - source compatibility is more important than
smoothing a few of C's rough edges.  Maybe the next breaking change release
this should be considered (python 4000... python 5000?)

___
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

Re: [Python-Dev] C99

[Sturla Molden]

Guido van Rossum  wrote:

> I'm talking about 3rd party extensions. Those may require source
> compatibility with older Python versions. All I'm asking for is to not
> require source-level use of C99 features. 

This of course removes a lot of its usefulness. E.g. macros cannot be
replaced by inline functions, as header files must still be plain C89.


Sturla Molden

___
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

Re: [Python-Dev] C99

[Meador Inge]

On Sat, Jun 4, 2016 at 1:11 AM, Benjamin Peterson 
wrote:


> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
> (in so much as GCC and MSVC support them)?
>

+1

# Meador
___
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

Re: [Python-Dev] C99

[Larry Hastings]

On 06/03/2016 11:11 PM, Benjamin Peterson wrote:

So, what say you to updating PEP 7 to allow C99 features for Python 3.6
(in so much as GCC and MSVC support them)?


+1

Clearly it'll be 3.5+ only, and clearly it'll be a specific list of 
features ("C89 but also permitting //-comments, variadic macros, 
variable declarations on any line, inline functions, and designated 
initializers").  But I'm looking forward to it!


We already had macros for inline (e.g. Py_LOCAL_INLINE), maybe we can 
remove those.



//arry/
___
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

Re: [Python-Dev] C99

[Christian Heimes]

On 2016-06-04 12:07, Guido van Rossum wrote:
> I'm talking about 3rd party extensions. Those may require source
> compatibility with older Python versions. All I'm asking for is to not
> require source-level use of C99 features. Of course requiring a
> specific compiler to work with specific CPython versions is fine.

Ah, the other way around. Yes, that makes a lot of sense.
___
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

Re: [Python-Dev] C99

[Guido van Rossum]

I'm talking about 3rd party extensions. Those may require source
compatibility with older Python versions. All I'm asking for is to not
require source-level use of C99 features. Of course requiring a
specific compiler to work with specific CPython versions is fine.

On Sat, Jun 4, 2016 at 12:05 PM, Christian Heimes  wrote:
> On 2016-06-04 11:59, Guido van Rossum wrote:
>> As long as we don't require extension module authors to use them --
>> they may have their own compatibility requirements.
>
> On Windows extension modules must be compiled with a specific version of
> MSVC any way. For Python 3.6 VS 2015 or newer is a hard requirement.
>
> We kept the old compiler directories around for embedders.
>



-- 
--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

Re: [Python-Dev] C99

[Christian Heimes]

On 2016-06-04 11:59, Guido van Rossum wrote:
> As long as we don't require extension module authors to use them --
> they may have their own compatibility requirements.

On Windows extension modules must be compiled with a specific version of
MSVC any way. For Python 3.6 VS 2015 or newer is a hard requirement.

We kept the old compiler directories around for embedders.

___
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

Re: [Python-Dev] C99

[Guido van Rossum]

As long as we don't require extension module authors to use them --
they may have their own compatibility requirements.

On Sat, Jun 4, 2016 at 11:50 AM, Christian Heimes  wrote:
> On 2016-06-04 10:47, Guido van Rossum wrote:
>> Funny. Just two weeks ago I was helping someone who discovered a
>> compiler that doesn't support the new relaxed variable declaration
>> rules. I think it was on Windows. Maybe this move is a little too
>> aggressively deprecating older Windows compilers?
>
> Yes, it's not support in VS 2012 and 2008 for Python 3.4 and older. New
> C99 features are available in VS 2013,
> https://blogs.msdn.microsoft.com/vcblog/2013/06/28/c1114-stl-features-fixes-and-breaking-changes-in-vs-2013/
>
>
> Python 3.5+ requires VS 2015 anyway. Traditionally we tried to keep
> backwards compatibility with older compiler versions. The new features
> are tempting enough to deprecate compiler versions that have been
> released more than five years ago.
>
> Christian



-- 
--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

Re: [Python-Dev] C99

[Christian Heimes]

On 2016-06-04 10:47, Guido van Rossum wrote:
> Funny. Just two weeks ago I was helping someone who discovered a
> compiler that doesn't support the new relaxed variable declaration
> rules. I think it was on Windows. Maybe this move is a little too
> aggressively deprecating older Windows compilers?

Yes, it's not support in VS 2012 and 2008 for Python 3.4 and older. New
C99 features are available in VS 2013,
https://blogs.msdn.microsoft.com/vcblog/2013/06/28/c1114-stl-features-fixes-and-breaking-changes-in-vs-2013/


Python 3.5+ requires VS 2015 anyway. Traditionally we tried to keep
backwards compatibility with older compiler versions. The new features
are tempting enough to deprecate compiler versions that have been
released more than five years ago.

Christian
___
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

Re: [Python-Dev] C99

[Benjamin Peterson]

On Sat, Jun 4, 2016, at 11:32, Dino Viehland wrote:
> 
> 
> Martin wrote:
> > On 4 June 2016 at 06:11, Benjamin Peterson  wrote:
> > > PEP 7 requires CPython to use C code conforming to the venerable C89
> > > standard. Traditionally, we've been stuck with C89 due to poor C
> > > support in MSVC. However, MSVC 2013 and 2015 implement the key
> > features of C99.
> > > C99 does not offer anything earth-shattering; here are the features I
> > > think we'd find most interesting:
> > > - Variable declarations can be on any line: removes possibly the most
> > > annoying limitation of C89.
> > > - Inline functions: We can make Py_DECREF and Py_INCREF inline
> > > functions rather than unpleasant macros.
> > > - C++-style line comments: Not an killer feature but commonly used.
> > > - Booleans
> > 
> > My most-missed C99 feature would be designated initializers. Does MSVC
> > support them? It might allow you to do away with those giant pasted slot
> > tables, and just write the slots you need:
> > 
> > PyTypeObject PyUnicodeIter_Type = {
> > PyVarObject_HEAD_INIT(_Type, 0)
> > .tp_name = "str_iterator",
> > .tp_basicsize = sizeof(unicodeiterobject),
> > .tp_dealloc = unicodeiter_dealloc,
> > .tp_getattro = PyObject_GenericGetAttr,
> > .tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,
> > .tp_traverse = unicodeiter_traverse,
> > .tp_iter = PyObject_SelfIter,
> > .tp_iternext = unicodeiter_next,
> > .tp_methods = unicodeiter_methods,
> > };
> 
> I checked and VC++ does actually support this, and it looks like they
> support 
> // comments  as well.  I don't think it fully supports all of the C99
> features - it appears 
> They just cherry picked some stuff.  The C99 standard library does appear
> to be fully
> supported with the exception of tgmath.h.

Are the C99 features VS++ supports documented anywhere? I couldn't find
any list.
___
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

Re: [Python-Dev] C99

[Dino Viehland via Python-Dev]

Martin wrote:
> On 4 June 2016 at 06:11, Benjamin Peterson  wrote:
> > PEP 7 requires CPython to use C code conforming to the venerable C89
> > standard. Traditionally, we've been stuck with C89 due to poor C
> > support in MSVC. However, MSVC 2013 and 2015 implement the key
> features of C99.
> > C99 does not offer anything earth-shattering; here are the features I
> > think we'd find most interesting:
> > - Variable declarations can be on any line: removes possibly the most
> > annoying limitation of C89.
> > - Inline functions: We can make Py_DECREF and Py_INCREF inline
> > functions rather than unpleasant macros.
> > - C++-style line comments: Not an killer feature but commonly used.
> > - Booleans
> 
> My most-missed C99 feature would be designated initializers. Does MSVC
> support them? It might allow you to do away with those giant pasted slot
> tables, and just write the slots you need:
> 
> PyTypeObject PyUnicodeIter_Type = {
> PyVarObject_HEAD_INIT(_Type, 0)
> .tp_name = "str_iterator",
> .tp_basicsize = sizeof(unicodeiterobject),
> .tp_dealloc = unicodeiter_dealloc,
> .tp_getattro = PyObject_GenericGetAttr,
> .tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,
> .tp_traverse = unicodeiter_traverse,
> .tp_iter = PyObject_SelfIter,
> .tp_iternext = unicodeiter_next,
> .tp_methods = unicodeiter_methods,
> };

I checked and VC++ does actually support this, and it looks like they support 
// comments  as well.  I don't think it fully supports all of the C99 features 
- it appears 
They just cherry picked some stuff.  The C99 standard library does appear to be 
fully
supported with the exception of tgmath.h.


___
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

Re: [Python-Dev] C99

[Guido van Rossum]

Funny. Just two weeks ago I was helping someone who discovered a
compiler that doesn't support the new relaxed variable declaration
rules. I think it was on Windows. Maybe this move is a little too
aggressively deprecating older Windows compilers?

On Sat, Jun 4, 2016 at 10:27 AM, Christian Heimes  wrote:
> On 2016-06-03 23:11, Benjamin Peterson wrote:
>> PEP 7 requires CPython to use C code conforming to the venerable C89
>> standard. Traditionally, we've been stuck with C89 due to poor C support
>> in MSVC. However, MSVC 2013 and 2015 implement the key features of C99.
>> C99 does not offer anything earth-shattering; here are the features I
>> think we'd find most interesting:
>> - Variable declarations can be on any line: removes possibly the most
>> annoying limitation of C89.
>> - Inline functions: We can make Py_DECREF and Py_INCREF inline functions
>> rather than unpleasant macros.
>> - C++-style line comments: Not an killer feature but commonly used.
>> - Booleans
>> In summary, some niceties that would make CPython hacking a little more
>> fun.
>>
>> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
>> (in so much as GCC and MSVC support them)?
>
> +1
>
> - We never officially deprecated C89 platforms withou 64 bit integers in
> PEP 7. Victor's changes to pytime.h implies support for uint64_t and
> int64_t. C99 has mandatory long long int support.
>
> - If we also drop Solaris Studio C compiler support, we can replace
> header guards (e.g. #ifndef Py_PYTHON_H) with #pragma once
>
> Christian
>
>
>
> ___
> 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

Re: [Python-Dev] C99

[Christian Heimes]

On 2016-06-03 23:11, Benjamin Peterson wrote:
> PEP 7 requires CPython to use C code conforming to the venerable C89
> standard. Traditionally, we've been stuck with C89 due to poor C support
> in MSVC. However, MSVC 2013 and 2015 implement the key features of C99.
> C99 does not offer anything earth-shattering; here are the features I
> think we'd find most interesting:
> - Variable declarations can be on any line: removes possibly the most
> annoying limitation of C89.
> - Inline functions: We can make Py_DECREF and Py_INCREF inline functions
> rather than unpleasant macros.
> - C++-style line comments: Not an killer feature but commonly used.
> - Booleans
> In summary, some niceties that would make CPython hacking a little more
> fun.
> 
> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
> (in so much as GCC and MSVC support them)?

+1

- We never officially deprecated C89 platforms withou 64 bit integers in
PEP 7. Victor's changes to pytime.h implies support for uint64_t and
int64_t. C99 has mandatory long long int support.

- If we also drop Solaris Studio C compiler support, we can replace
header guards (e.g. #ifndef Py_PYTHON_H) with #pragma once

Christian



___
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

Re: [Python-Dev] C99

[Sebastian Krause]

Martin Panter  wrote:
>> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
>> (in so much as GCC and MSVC support them)?
>
> Sounds good for features that are well-supported by compilers that
> people use. (Are there other compilers used than just GCC and MSVC?)

clang on OS X, but it supports pretty much everything that GCC
supports as well.
___
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

Re: [Python-Dev] C99

[Martin Panter]

On 4 June 2016 at 06:11, Benjamin Peterson  wrote:
> PEP 7 requires CPython to use C code conforming to the venerable C89
> standard. Traditionally, we've been stuck with C89 due to poor C support
> in MSVC. However, MSVC 2013 and 2015 implement the key features of C99.
> C99 does not offer anything earth-shattering; here are the features I
> think we'd find most interesting:
> - Variable declarations can be on any line: removes possibly the most
> annoying limitation of C89.
> - Inline functions: We can make Py_DECREF and Py_INCREF inline functions
> rather than unpleasant macros.
> - C++-style line comments: Not an killer feature but commonly used.
> - Booleans

My most-missed C99 feature would be designated initializers. Does MSVC
support them? It might allow you to do away with those giant pasted
slot tables, and just write the slots you need:

PyTypeObject PyUnicodeIter_Type = {
PyVarObject_HEAD_INIT(_Type, 0)
.tp_name = "str_iterator",
.tp_basicsize = sizeof(unicodeiterobject),
.tp_dealloc = unicodeiter_dealloc,
.tp_getattro = PyObject_GenericGetAttr,
.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,
.tp_traverse = unicodeiter_traverse,
.tp_iter = PyObject_SelfIter,
.tp_iternext = unicodeiter_next,
.tp_methods = unicodeiter_methods,
};

> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
> (in so much as GCC and MSVC support them)?

Sounds good for features that are well-supported by compilers that
people use. (Are there other compilers used than just GCC and MSVC?)
___
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

Re: [Python-Dev] c99 comments in the 2.6 code base?

[Christian Heimes]

Fredrik Lundh wrote:

http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/

mentions that Objects/frameobject.c contains a C99-style comment, which 
means that Python 2.6 won't build on AIX.


shouldn't we use a suitable gcc option for the buildbots to prevent that 
from happening?


Ouch! This shouldn't have happend. I'm going to discuss the matter on 
#python-dev. Perhaps --with-pydebug could add more restrict error 
checking to the Makefile like -std=c89 -pedantic -Werror


Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c99 comments in the 2.6 code base?

[Antoine Pitrou]

Christian Heimes lists at cheimes.de writes:
 
 Ouch! This shouldn't have happend. I'm going to discuss the matter on 
 #python-dev. Perhaps --with-pydebug could add more restrict error 
 checking to the Makefile like -std=c89 -pedantic -Werror

As discussed on python-dev, I think it should also be added in release mode.
Some developers probably never compile in debug mode (*), and compiling in
release mode is useful when you want to do performance tuning.

(*) not thinking of anyone in particular !

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c99 comments in the 2.6 code base?

[Christian Heimes]

Fredrik Lundh wrote:

http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/


I've found several more occasions of // comments and one usage of 
inline. We *really* should have some way to compile Python with C89 checks


Python doesn't compile with the -pedantic option but it compiles with 
-std=c89 -Werror after I've applied some patches. I've added a new make 
command to add extra checks. Maybe the build bots could use make c89 
instead of make to build Python?


c89:
$(MAKE) CFLAGS=$(CFLAGS) -std=c89 -Werror


Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c99 comments in the 2.6 code base?

[Christian Heimes]

Martin v. Löwis wrote:

shouldn't we use a suitable gcc option for the buildbots to prevent that
from happening?


Which one specifically?


I suggest we add -std=c89 to CFLAGS. We could also add a new target 
called buildbot to the Makefile that appends -std=c89 -Werror to 
CFLAGS. I don't think it's wise to add -Werror to the standard build 
target. However a new build target with extra checks should help to 
detect errors much sooner.


Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c99 comments in the 2.6 code base?

[Martin v. Löwis]

 shouldn't we use a suitable gcc option for the buildbots to prevent that
 from happening?

 Which one specifically?
 
 I suggest we add -std=c89 to CFLAGS.

That needs thorough testing, in particular across many old Linux
distributions. It might be that some sets of Linux header files
rely on GNU C extensions, without using the __extension__ keyword.

 We could also add a new target
 called buildbot to the Makefile that appends -std=c89 -Werror to
 CFLAGS. I don't think it's wise to add -Werror to the standard build
 target. However a new build target with extra checks should help to
 detect errors much sooner.

That would need to go along with a policy that Python must never cause
GCC to emit any warnings.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c99 comments in the 2.6 code base?

[skip]

 shouldn't we use a suitable gcc option for the buildbots to prevent
 that from happening?
 
 Which one specifically?
 
 I suggest we add -std=c89 to CFLAGS.

Martin That needs thorough testing, in particular across many old Linux
Martin distributions. It might be that some sets of Linux header files
Martin rely on GNU C extensions, without using the __extension__
Martin keyword.

Surely we don't need to be that careful with the buildbots do we?  If
anything, I think it would be a good idea to be more strict for them than
the default.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99 code in the Python core?

[Matthieu Brucher]

2008/7/5 Mark Dickinson [EMAIL PROTECTED]:
 I have a general question and a specific question.  First the general one:

 (1) When is it okay to use C99 code in the Python core?  More particularly,
 is it considered acceptable to use widely-implemented library functions that
 are specified in C99 but not ANSI C, or widely-implemented features that
 are new to C99?

 Or is C99 code now acceptable pretty much anywhere?  If so, should
 PEP 7 be updated?  It currently says: Use ANSI/ISO standard C
 (the 1989 version of the standard).

 I think there are some C99 features that still aren't implemented
 everywhere, even on major platforms.  (Examples are the inverse hyperbolic
 trig functions in math.h.)

Hi,

I don't think that C99 is not supported by Visual Studio and there are
no plan for Microsoft to do so.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99 code in the Python core?

[Martin v. Löwis]

 (1) When is it okay to use C99 code in the Python core?  More particularly,
 is it considered acceptable to use widely-implemented library functions that
 are specified in C99 but not ANSI C, or widely-implemented features that
 are new to C99?

[C99 is also ANSI C, IIUC. ANSI has adopted ISO/IEC 9899:1999 as a U.S.
 national standard.]

It's ok to use functions of the C99 standard library if you have a
configure test and a fall-back implementation, or if you know that the
function is available on all systems we care about.

 Or is C99 code now acceptable pretty much anywhere?

No. As others have pointed out, Microsoft still hasn't implemented in
Visual C.

 If so, should
 PEP 7 be updated?  It currently says: Use ANSI/ISO standard C
 (the 1989 version of the standard).

No.

 (2) Is it okay to use the '%a' format specifier for sprintf, sscanf and 
 friends.
 Are there major platforms where this isn't implemented?  (Using
 '%a' would make the issue implementation much simpler.)

It's implemented in VS 2008, see

http://msdn.microsoft.com/en-us/library/hf4y5e3w.aspx

On the other hand, people still might try to run Python on older
versions of Solaris, such as Solaris 2.6 (which was released 1997).
I don't know when Solaris' CRT first started to support this.

I'd add a configure test, and, at run-time, raise an exception
if the C library doesn't support it yet somebody tries to use it.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com