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.
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 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 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 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
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 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
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 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
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.
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.
>
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
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
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
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
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
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
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
18 matches
Mail list logo
