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
> 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
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
> -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 wrote:
>
> > I'm
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
On 05.06.16 21:24, Raymond Hettinger wrote:
On Jun 4, 2016, at 1:08 AM, Serhiy Storchaka wrote:
1. http://bugs.python.org/issue27129
Make the bytecode more 16-bit oriented.
I don' think this should be done. Adding the /2 and *2 just complicates the
code and messes with
> On Jun 4, 2016, at 1:08 AM, Serhiy Storchaka wrote:
>
> Following the converting 8-bit bytecode to 16-bit bytecode (wordcode), there
> are other issues for improving the bytecode.
>
> 1. http://bugs.python.org/issue27129
> Make the bytecode more 16-bit oriented.
I don'