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 with 3.6.

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 need to worry about compilers that don't
implement C99 features like inline functions in C. How long have the Linux
kernel used inline functions instead of macros? 20 years or more?

Sturla

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 need to worry about compilers that don't
> implement C99 features like inline functions in C. How long have the
> Linux
> kernel used inline functions instead of macros? 20 years or more?

Using inline functions instead of macros doesn't have to mean anything
but a performance hit on platforms that don't support them, since the
inline keyword, or some other identifier, could be defined to expand to
an empty token sequence on platforms that do not support it. It's much
lower impact on the source code than some other C99 features.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 will taint the C89 purity of their source code.
>>
>> Personally I don't think we need to worry about compilers that don't
>> implement C99 features like inline functions in C. How long have the
>> Linux
>> kernel used inline functions instead of macros? 20 years or more?
>
> Using inline functions instead of macros doesn't have to mean anything
> but a performance hit on platforms that don't support them, since the
> inline keyword, or some other identifier, could be defined to expand to
> an empty token sequence on platforms that do not support it. It's much
> lower impact on the source code than some other C99 features.

That could be a major performance impact.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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. Also if I compile it for 3.5 and it only uses
>> the ABI it should still be linkable with 3.6.
>
> 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.

Well, they should use the right compiler for the Python version they
are targeting. I'm just saying that they can't afford C99 features in
their own code. Not even to call C/Python APIs. I think it would be
okay if e.g. Py_INCREF was an inline function in Python 3.6, as long
as the way you use it remains the same.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 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.
>>
>> 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.
> 
> Well, they should use the right compiler for the Python version they
> are targeting. I'm just saying that they can't afford C99 features in
> their own code. Not even to call C/Python APIs. I think it would be
> okay if e.g. Py_INCREF was an inline function in Python 3.6, as long
> as the way you use it remains the same.

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 different, but so would the compilers. It's the
extension module source code that must be the same in the two scenarios.

We're not saying that an extension module must compile with a C89
compiler under 3.6.

Eric.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 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.
>>>
>>> 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.
>>
>> Well, they should use the right compiler for the Python version they
>> are targeting. I'm just saying that they can't afford C99 features in
>> their own code. Not even to call C/Python APIs. I think it would be
>> okay if e.g. Py_INCREF was an inline function in Python 3.6, as long
>> as the way you use it remains the same.
>
> 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 different, but so would the compilers. It's the
> extension module source code that must be the same in the two scenarios.
>
> We're not saying that an extension module must compile with a C89
> compiler under 3.6.
>
> Eric.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[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 generators 
PEP.  Let's pretend that we have them already: if we have a 'yield' 
expression in an 'async def' function, the function becomes an 
"asynchronous generator function":


   async def foo():
  await bar()
  yield 1
  await baz()
  yield 2

   # foo -- is an `asynchronous generator function`
   # foo() -- is an `asynchronous generator`

If we iterate through "foo()", it will await on "bar()", yield "1", 
await on "baz()", and yield "2":


   >>> async for el in foo():
   ... print(el)
   1
   2

If we decide to have a class with an __aiter__ that is an async 
generator, we'd write something like this:


   class Foo:
  async def __aiter__(self):
  await bar()
  yield 1
  await baz()
  yield 2

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.


I'm still working on the PEP for async generators, targeting CPython 
3.6.  And once it is ready, it might still be rejected or deferred.  But 
in any case, this PEP 492 flaw has to be fixed now, in 3.5.2 (since PEP 
492 is provisional).


I've created an issue on the bug tracker: http://bugs.python.org/issue27243

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 following coroutine:


async def wrapper(aiter_result):
return aiter_result

3. If the returned object does not have an '__anext__' method, a 
DeprecationWarning is raised.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 __aiter__ being an awaitable 
during the original PEP 492 review process. You added an explanation to the PEP 
but I don’t think we ever had an example where this was needed. I’m +1 to 
resolve this now.

> 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 following coroutine:
> 
>async def wrapper(aiter_result):
>return aiter_result
> 
> 3. If the returned object does not have an '__anext__' method, a 
> DeprecationWarning is raised.

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 is going to get released, are they going to get it? I’m pretty sure wily 
isn’t and yakkety is but just wanted to confirm; especially with xenial being 
an LTS release.

--
Not-that-i-see-a-different-way-out’sly yours,
Ł


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 
following coroutine:


   async def wrapper(aiter_result):
   return aiter_result

3. If the returned object does not have an '__anext__' method, a 
DeprecationWarning is raised.


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 is going to get released, are they 
going to get it? I’m pretty sure wily *isn’t* and yakkety *is* but 
just wanted to confirm; especially with xenial being an LTS release.




Yes, I agree. OTOH, I don't see any other way of resolving this.

Another option would be to start raising the DeprecationWarning only in 3.6.

Yury
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 Mon, Jun 6, 2016 at 1:05 PM, Yury Selivanov 
wrote:

>
>
> 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 following coroutine:
>>>
>>>async def wrapper(aiter_result):
>>>return aiter_result
>>>
>>> 3. If the returned object does not have an '__anext__' method, a
>>> DeprecationWarning is raised.
>>>
>>
>> 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 is going to get released, are they going to get
>> it? I’m pretty sure wily *isn’t* and yakkety *is* but just wanted to
>> confirm; especially with xenial being an LTS release.
>>
>>
> Yes, I agree. OTOH, I don't see any other way of resolving this.
>
> Another option would be to start raising the DeprecationWarning only in
> 3.6.
>
> Yury
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 is going to get released, are they going to get
>it? I’m pretty sure wily isn’t and yakkety is but just wanted to confirm;
>especially with xenial being an LTS release.

Matthias and I talked briefly about this at Pycon.  We want to get 3.5.2 into
Ubuntu 16.04.1 if it's released in time.  16.04.1 is currently scheduled for
July 21st [1] so if Larry keeps with his announced schedule that should work
out[2].

Obviously it would make it into Yakkety too.  It's not worth it for Wily
(15.10) since that EOLs next month.

Cheers,
-Barry

[1] https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
[2] https://mail.python.org/pipermail/python-dev/2016-April/144383.html


pgpI_nU_ukCmy.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 different, but so would the compilers.


On Windows, the compiler would be the 2015 MS compiler in both cases. 
Steve Dower would know if compiler flags need to be changed to enable or 
stop disabling C99 features.


> It's the

extension module source code that must be the same in the two scenarios.


We could run the experiment ourselves by changing one or more .h files 
to include one or more of the C99 features we want while leaving our .c 
files alone in the sense of remaining C89 compatible.  Compile and run 
the test suite.  If successful, add more.  We would soon find out 
whether any of the features we want in header files require use of C99 
features in .c files that include them.  With a .h standard established, 
we could then revise *our* .c files without imposing the same on 
extensions.



--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com