Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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,

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

> 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: [Pyth

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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.

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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,

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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.

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

I think these features may improve C code readability. (Easy feature first). * // one line comment * inline function static inline function can be used instead of may macros. It is more readable, and type safe. * Designated Initializers; { .key = value };

Re: [Python-Dev] C99

Different question. What features are we actually talking about? Is it possible to enumerate them? The only thing I'm aware of is declarations following non-declarations in the same block, but I'm no C expert any more. On Fri, Aug 5, 2016 at 8:43 PM, Ned Deily wrote: > On Aug

Re: [Python-Dev] C99

On Aug 5, 2016, at 23:02, Nick Coghlan wrote: > As a pragmatic requirement, what if we went with: > > - must compile with the Python 3.5 Windows compiler (so MSVC 14.0) > - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) > - must compile with the

Re: [Python-Dev] C99

On 6 August 2016 at 12:15, Steve Dower wrote: > FYI, it's MSVC 14.0 (which is included in VS 2015). > > Personally I'd like to see it restricted to the common subset of C99 and > some version of C++ (which is obviously mostly C and includes no C++), > because I know there

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

On Fri, 5 Aug 2016 at 15:07 Guido van Rossum wrote: > That sounds fine to me, but we need to list specific compiler versions. > Would you want this to be static (e.g. MSVC 2016 until we choose to update to support C11), or would you want it to vary based on what's

Re: [Python-Dev] C99

I think if we want to revisit this in the future it should be an explicit change. On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon wrote: > > > On Fri, 5 Aug 2016 at 15:17 Guido van Rossum wrote: >> >> I want it to list specific versions that are known to be

Re: [Python-Dev] C99

On Fri, 5 Aug 2016 at 15:17 Guido van Rossum wrote: > I want it to list specific versions that are known to be good right > now, so we can point fingers appropriately when a regression happens. > OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are the

Re: [Python-Dev] C99

I want it to list specific versions that are known to be good right now, so we can point fingers appropriately when a regression happens. If you have to ask Steve what version he used, ask! On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon wrote: > > > On Fri, 5 Aug 2016 at 15:07

Re: [Python-Dev] C99

That sounds fine to me, but we need to list specific compiler versions. On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon wrote: > Where did we finally land on this discussion? Do we want to update PEP 7 to > say that starting in 3.6 we may use C99 features common to all supported >

Re: [Python-Dev] C99

Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)? On Wed, 8 Jun 2016 at 01:28 Victor Stinner

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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.

Re: [Python-Dev] C99

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,

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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,

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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.

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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,

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

Re: [Python-Dev] C99

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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