RetroSearch Browse

Sun Jun 5 22:42:12 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-June/144839.html

> From: Python-Dev [mailto:python-dev-
> bounces+vgr255=live.ca at python.org] On Behalf Of tritium-
> list at sdamon.com
> Sent: Sunday, June 05, 2016 10:35 PM
> To: 'Sturla Molden'; python-dev at python.org
> Subject: Re: [Python-Dev] C99
> 
> > -----Original Message-----
> > From: Python-Dev [mailto:python-dev-bounces+tritium-
> > list=sdamon.com at python.org] On Behalf Of Sturla Molden
> > Sent: Sunday, June 5, 2016 10:29 PM
> > To: python-dev at python.org
> > Subject: Re: [Python-Dev] C99
> >
> > Guido van Rossum <guido at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-June/144839.html below:

[Python-Dev] C99