Re: [Python-Dev] C99

2016-06-06 Thread Terry Reedy
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] PEP 492: __aiter__ should return async iterator directly instead of awaitable

2016-06-06 Thread Barry Warsaw
On Jun 06, 2016, at 01:02 PM, Łukasz Langa wrote: >There’s a problem with this approach. It will force people to write >deprecated code because you never know if your library is going to run on >3.5.0 or 3.5.1. Barry, Ubuntu wily, xenial and yakkety currently package >3.5.0 or 3.5.1. When 3.5.2

Re: [Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

2016-06-06 Thread Guido van Rossum
The RC for 3.5.2 is going out coming weekend (see PEP 478 ). We should get this out now, or make it the first incompatibility in 3.6 (that's also an option; 3.6 feature freeze starts September, see PEP 494 ). On

Re: [Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

2016-06-06 Thread Yury Selivanov
On 2016-06-06 4:02 PM, Łukasz Langa wrote: The proposed patch fixes the __aiter__ in a backwards compatible way: 1. ceval/GET_AITER opcode calls the __aiter__ method. 2. If the returned object has an '__anext__' method, GET_AITER silently wraps it in an awaitable, which is equivalent to the

Re: [Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

2016-06-06 Thread Łukasz Langa
On Jun 6, 2016, at 12:23 PM, Yury Selivanov wrote: > > However, with the current PEP 492 design, the above code would be invalid! > The interpreter expects __aiter__ to return a coroutine, not an async > generator. > Yes, I remember asking about the reason behind

[Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

2016-06-06 Thread Yury Selivanov
There is a small flaw in PEP 492 design -- __aiter__ should not return an awaitable object that resolves to an asynchronous iterator. It should return an asynchronous iterator directly. Let me explain this by showing some examples. I've discovered this while working on a new asynchronous

Re: [Python-Dev] C99

2016-06-06 Thread Guido van Rossum
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

2016-06-06 Thread Eric V. Smith
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

2016-06-06 Thread Guido van Rossum
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

2016-06-06 Thread Guido van Rossum
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

2016-06-06 Thread Random832
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

2016-06-06 Thread Sturla Molden
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] cpython: replace custom validation logic in the parse module with a simple DFA validator

2016-06-06 Thread Benjamin Peterson
On Sat, Jun 4, 2016, at 17:26, Christian Heimes wrote: > 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