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 anythin
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.
2. http://bugs.python.org/issue27140
Add new opcode BUILD_CONST_KEY_MAP for building a dict with
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
It's not on the list but I'm hoping to convince Dino to work on END_FINALLY
to be a bit more sane.
On Sat, Jun 4, 2016, 01:17 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.p
You should get in touch with Mark Shannon, while you're working on
ceval. He has some definite improvements that can be made to the eval
loop.
-eric
On Sat, Jun 4, 2016 at 2:08 AM, Serhiy Storchaka wrote:
> Following the converting 8-bit bytecode to 16-bit bytecode (wordcode), there
> are other
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 ear
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
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.
>
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.
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
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
>> co
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
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,
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 CPytho
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
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://ma
On 2016-06-02 11:32, benjamin.peterson wrote:
> https://hg.python.org/cpython/rev/4a9159ea2536
> changeset: 101601:4a9159ea2536
> user:Benjamin Peterson
> date:Thu Jun 02 11:30:18 2016 -0700
> summary:
> replace custom validation logic in the parse module with a simple DFA
> v
On 04/06/16 10:02, Eric Snow wrote:
You should get in touch with Mark Shannon, while you're working on
ceval. He has some definite improvements that can be made to the eval
loop.
See http://bugs.python.org/issue17611 for my suggested improvements.
I've made a new comment there.
Cheers,
Mark.
18 matches
Mail list logo
