Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Greg, On 2015-04-29 1:40 AM, Greg Ewing wrote: Yury Selivanov wrote: I don't want this: "await a() * b()" to be parsed, it's not meaningful. Why not? If a() is a coroutine that returns a number, why shouldn't I be able to multiply it by something? Sorry, I thought you meant parsing "await

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: I don't want this: "await a() * b()" to be parsed, it's not meaningful. Why not? If a() is a coroutine that returns a number, why shouldn't I be able to multiply it by something? I don't think your currently proposed grammar prevents that anyway. We can have --> '*'

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 04/28, Guido van Rossum wrote: > On Tue, Apr 28, 2015 at 4:55 PM, Ethan Furman wrote: >> On 04/28, Yury Selivanov wrote: >> >> >>> This limitation will go away as soon as ``async`` and ``await`` ate >> >>> proper keywords. Or if it's decided to use a future import for this >> >>> PEP. >> >> `a

Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido, I found a solution how to disable 'yield from', iter()/tuple() and 'for..in' on native coroutines with 100% backwards compatibility. The idea is to add one more code object flag: CO_NATIVE_COROUTINE, which will be applied, along with CO_COROUTINE to all 'async def' functions. This way:

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: c) 'yield from' only accept coroutine objects from generators decorated with 'types.coroutine'. That means that existing asyncio generator-based coroutines will happily yield from both coroutin

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 29/04/2015 9:49 a.m., Guido van Rossum wrote: c) 'yield from' only accept coroutine objects from generators decorated with 'types.coroutine'. That means that existing asyncio generator-based coroutines will happily yield from both coroutines and generators. *But* every gene

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Stephen, Thanks a lot for the feedback and suggestions. I'll apply them to the PEP. On 2015-04-28 11:03 PM, Stephen J. Turnbull wrote: Literary critic here. In section "Specification" > It is strongly suggested that the reader understands how coroutines > are implemented in Python (PEP

[Python-Dev] PEP 492: async/await in Python; v3

Literary critic here. In section "Specification" > It is strongly suggested that the reader understands how coroutines > are implemented in Python (PEP 342 and PEP 380). It is also > recommended to read PEP 3156 (asyncio framework) and PEP 3152 > (Cofunctions). The usual phrasing of "strong

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

I don't care for await await x. On Apr 28, 2015 6:53 PM, "Yury Selivanov" wrote: > Looking at the grammar -- the only downside of the current approach is that > you can't do 'await await fut'. I still think that it reads better with > parens. If we put 'await' to 'factor' terminal we would allo

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Looking at the grammar -- the only downside of the current approach is that you can't do 'await await fut'. I still think that it reads better with parens. If we put 'await' to 'factor' terminal we would allow await -fut # await (-fut) I think I something like power: atom_expr ['**'

Re: [Python-Dev] PEP 492: async/await in Python; v3

On Tue, Apr 28, 2015 at 4:55 PM, Ethan Furman wrote: > On 04/28, Yury Selivanov wrote: > > >>> This limitation will go away as soon as ``async`` and ``await`` ate > >>> proper keywords. Or if it's decided to use a future import for this > >>> PEP. > > `async` and `await` need to be proper keywor

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 04/28, Yury Selivanov wrote: >>> This limitation will go away as soon as ``async`` and ``await`` ate >>> proper keywords. Or if it's decided to use a future import for this >>> PEP. `async` and `await` need to be proper keywords, and __future__ imports is how we do that (see, e.g., PEP 355 a

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Guido, Thank you for a very detailed review. Comments below: On 2015-04-28 5:49 PM, Guido van Rossum wrote: Inline comments below... On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov wrote: Hi python-dev, Another round of updates. Reference implementation has been updated: https://githu

Re: [Python-Dev] PEP 492: async/await in Python; v3

Inline comments below... On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov wrote: > Hi python-dev, > > Another round of updates. Reference implementation > has been updated: https://github.com/1st1/cpython/tree/await > (includes all things from the below summary of updates + > tests). > > > Summa

Re: [Python-Dev] Issues with PEP 482 (1)

On Tue, Apr 28, 2015 at 1:22 PM, Mark Shannon wrote: > > > On 28/04/15 21:06, Guido van Rossum wrote: > >> On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon > > wrote: >> >> Hi, >> >> I still think that there are several issues that need addressing >> with PEP 492.

Re: [Python-Dev] Issues with PEP 482 (1)

On 28/04/15 21:06, Guido van Rossum wrote: On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon mailto:m...@hotpy.org>> wrote: Hi, I still think that there are several issues that need addressing with PEP 492. This time, one issue at a time :) "async" The "Rationale and Goals"

[Python-Dev] Unicode literals in Python 2.7

Hello, is it possible to somehow tell Python 2.7 to compile a code entered in the interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm considering adding support for Python 2 in my package ( https://github.com/Drekin/win-unicode-console) and I have run into the fact that when u"α" is ent

Re: [Python-Dev] Issues with PEP 482 (1)

On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon wrote: > Hi, > > I still think that there are several issues that need addressing with PEP > 492. This time, one issue at a time :) > > "async" > > The "Rationale and Goals" of PEP 492 states that PEP 380 has 3 > shortcomings. > The second of which i

Re: [Python-Dev] PEP 492: No new syntax is required

On Tue, Apr 28, 2015 at 11:51 AM, Stefan Behnel wrote: > Mark Shannon schrieb am 27.04.2015 um 09:48: > > On 27/04/15 00:13, Guido van Rossum wrote: > >> Currently this means looking for yield [from]; PEP 492 just adds looking > >> for await and async [for|with]. Making await() a function defeats

Re: [Python-Dev] Issues with PEP 482 (1)

On 28/04/15 20:39, Paul Sokolovsky wrote: Hello, On Tue, 28 Apr 2015 19:44:53 +0100 Mark Shannon wrote: [] A coroutine without a yield statement can be defined simply and concisely, thus: @coroutine def f(): return 1 [] A pure-python definition of the "coroutine" decorator is gi

Re: [Python-Dev] PEP 492: No new syntax is required

On 28/04/15 20:24, Paul Sokolovsky wrote: Hello, [snip] Based on all this passage, my guess is that you miss difference between C and Python functions. This is rather patronising, almost to the point of being insulting. Please keep the debate civil. [snip] Cheers, Mark. _

Re: [Python-Dev] Issues with PEP 482 (1)

Mark, I'm sorry but you have to view the proposal as a whole. Discussing it point by point in isolation doesn't make any sense, as with any complex subject. Thanks, Yury On 2015-04-28 2:44 PM, Mark Shannon wrote: Hi, I still think that there are several issues that need addressing with PE

[Python-Dev] Looking for someone to audit PEP 3156 (asyncio) against current version

PEP 3156 (Asynchronous IO Support Rebooted: the "asyncio" Module) was accepted 18 months ago, and since then we've aggressively test-driven it in the 3.4 stdlib. I think that in some cases we've changed or added APIs or changed semantics, and I would like to update the PEP to match reality (so that

Re: [Python-Dev] PEP 492: No new syntax is required

Mark Shannon schrieb am 27.04.2015 um 09:48: > On 27/04/15 00:13, Guido van Rossum wrote: >> Currently this means looking for yield [from]; PEP 492 just adds looking >> for await and async [for|with]. Making await() a function defeats the >> purpose because now aliasing can hide its presence, and w

[Python-Dev] Issues with PEP 482 (1)

Hi, I still think that there are several issues that need addressing with PEP 492. This time, one issue at a time :) "async" The "Rationale and Goals" of PEP 492 states that PEP 380 has 3 shortcomings. The second of which is: """It is not possible to natively define a coroutine which has

Re: [Python-Dev] A macro for easier rich comparisons

On Tue, 2015-04-28 at 10:50 -0700, Glenn Linderman wrote: > On 4/28/2015 2:13 AM, Victor Stinner wrote: > > > > #define Py_RETURN_RICHCOMPARE(val1, val2, op) > > > \ > > > > do { > > > > \ > > >

Re: [Python-Dev] A macro for easier rich comparisons

On 4/28/2015 2:13 AM, Victor Stinner wrote: #define Py_RETURN_RICHCOMPARE(val1, val2, op) \ > do {\ > switch (op) { \ > case

Re: [Python-Dev] PEP 492: No new syntax is required

On 4/26/2015 4:32 PM, Paul Sokolovsky wrote: Then, is the only logic for proposing __aenter__ is to reinsure against a situation that someone starts to write async context manager, forgets that they write async context manager, and make an __enter__ method there. Then your implementation will ann

Re: [Python-Dev] PEP 492: async/await in Python; v3

Ethan, On 2015-04-28 11:29 AM, Ethan Furman wrote: On 04/28, Yury Selivanov wrote: On 2015-04-28 1:43 AM, Stefan Behnel wrote: Should a Generator then inherit from both Iterator and Coroutine, or would that counter your intention to separate coroutines from generators as a concept? I mean, the

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 04/28, Yury Selivanov wrote: > On 2015-04-28 1:43 AM, Stefan Behnel wrote: >> Should a Generator then inherit from both Iterator and Coroutine, or would >> that counter your intention to separate coroutines from generators as a >> concept? I mean, they do share the same interface ... > > Them

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Stefan, On 2015-04-28 1:43 AM, Stefan Behnel wrote: Should a Generator then inherit from both Iterator and Coroutine, or would that counter your intention to separate coroutines from generators as a concept? I mean, they do share the same interface ... Them sharing the same interface depend

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Walter, On 2015-04-28 10:23 AM, Walter Dörwald wrote: Key properties of coroutines: * ``async def`` functions are always coroutines, even if they do not contain ``await`` expressions. * It is a ``SyntaxError`` to have ``yield`` or ``yield from`` expressions in an ``async`` function. Does

Re: [Python-Dev] A macro for easier rich comparisons

On Apr 28, 2015, at 11:13 AM, Victor Stinner wrote: >It would be nice to have a six module for C extensions. I'm quite sure >that many projects are already full of #ifdef PYTHON3 ... #else ... >#endif macros. Maybe encapsulating some of the recommendations here: https://wiki.python.org/moin/Port

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 28 Apr 2015, at 5:07, Yury Selivanov wrote: Hi python-dev, Another round of updates. Reference implementation has been updated: https://github.com/1st1/cpython/tree/await (includes all things from the below summary of updates + tests). [...] New Coroutine Declaration Syntax ---

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

I prefer option #3. On Mon, Apr 27, 2015 at 4:44 PM, Yury Selivanov wrote: > Hi Greg, > > I don't want this: "await a() * b()" to be parsed, it's not meaningful. > > Likely you'll see "await await a()" only once in your life, so I'm fine to > use parens for it (moreover, I think it reads better w

Re: [Python-Dev] A macro for easier rich comparisons

Hi, 2015-04-27 16:02 GMT+02:00 Petr Viktorin : > A macro like this would reduce boilerplate in stdlib and third-party C > extensions. It would ease porting C extensions to Python 3, where rich > comparison is mandatory. It would be nice to have a six module for C extensions. I'm quite sure that m

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 20:39:55 -0400 Yury Selivanov wrote: [] > > As for 3rd point, I'd like to remind that CPython is only one Python > > implementation. And with my MicroPython hat on, I'd like to know if > > (some of) these new features are "bloat" or "worthy" for the space > > constrai

[Python-Dev] A macro for easier rich comparisons

It seems the discussion on python-ideas, and also the patch review, died down. So I'm posting to python-dev. A macro like this would reduce boilerplate in stdlib and third-party C extensions. It would ease porting C extensions to Python 3, where rich comparison is mandatory. #define Py_RETURN_RIC

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 16:13:43 -0700 Guido van Rossum wrote: > But new syntax is the whole point of the PEP. I want to be able to > *syntactically* tell where the suspension points are in coroutines. > Currently this means looking for yield [from]; PEP 492 just adds > looking for await and

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 19:45:30 -0400 Yury Selivanov wrote: [] > > Then, is the only logic for proposing __aenter__ is to reinsure > > against a situation that someone starts to write async context > > manager, forgets that they write async context manager, and make an > > __enter__ method

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 18:49:43 -0400 Yury Selivanov wrote: [] > >> >- it would look confusing > > Sorry, "async def __enter__" doesn't look more confusing than > > "__aenter__" (vs "__enter__"). > > I'll update the PEP. > > The argument shouldn't be that it's confusing, the argument > is

Re: [Python-Dev] PEP 492: No new syntax is required

Hello, On Sun, 26 Apr 2015 16:40:03 -0400 Yury Selivanov wrote: > Hi Mark, > > On 2015-04-26 4:21 PM, Mark Shannon wrote: > > Hi, > > > > I was looking at PEP 492 and it seems to me that no new syntax is > > required. > > Mark, all your points are explained in the PEP in a great detail: Inde

Re: [Python-Dev] async/await in Python; v2

On 25 April 2015 at 22:02, Yury Selivanov wrote: [...] > On 2015-04-25 4:47 PM, Arnaud Delobelle wrote: [...] >> 1. About the 'async for' construct. Each iteration will create a new >> coroutine object (the one returned by Cursor.__anext__()) and it seems >> to me that it can be wasteful. In th