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

Out of curiosity, how much of a breaking change would making unary operators stack arbitrarily be? On 4/30/2015 23:57, Nathaniel Smith wrote: On Apr 30, 2015 8:40 PM, "Guido van Rossum" > wrote: > > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith

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

Nathaniel Smith wrote: If await acted like -, then this would be await (x ** 2) But with the proposed grammar, it's instead (await x) ** 2 Ah, I had missed that! This is a *good* argument for Yuri's grammar. I withdraw my objection now. -- Greg ___

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

On Apr 30, 2015 8:40 PM, "Guido van Rossum" wrote: > > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith wrote: >> >> The actual effect of making "await" a different precedence is to resolve the ambiguity in >> >> await x ** 2 >> >> If await acted like -, then this would be >> await (x ** 2) >

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

On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith wrote: > The actual effect of making "await" a different precedence is to resolve > the ambiguity in > > await x ** 2 > > If await acted like -, then this would be > await (x ** 2) > But with the proposed grammar, it's instead > (await x) **

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

On Apr 30, 2015 1:57 AM, "Greg Ewing" wrote: > > Nathaniel Smith wrote: >> >> Even if we put aside our trained intuitions about arithmetic, I think >> it's correct to say that the way unary minus is parsed is: everything >> to the right of it that has a tighter precedence gets collected up and >>

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

On Thu, Apr 30, 2015 at 6:56 PM, Devin Jeanpierre wrote: > On Thu, Apr 30, 2015 at 6:13 PM, Greg wrote: > > It's not about requiring or not requiring parens. It's about > > making the simplest possible change to the grammar necessary > > to achieve the desired goals. Keeping the grammar simple >

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

On Thu, Apr 30, 2015 at 6:13 PM, Greg wrote: > It's not about requiring or not requiring parens. It's about > making the simplest possible change to the grammar necessary > to achieve the desired goals. Keeping the grammar simple > makes it easy for humans to reason about. > > The question is whet

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

On 1/05/2015 6:04 a.m., Yury Selivanov wrote: I still want to see where my current grammar forces to use parens. See [1], there are no useless parens anywhere. It's not about requiring or not requiring parens. It's about making the simplest possible change to the grammar necessary to achieve

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

On 1/05/2015 5:38 a.m., Guido van Rossum wrote: you can write "not -x" but you can't write "- not x". That seems just as arbitrary and unintuitive, though. There are some other unintuitive consequences as well, e.g. you can write not a + b but it's not immediately obvious that this is par

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

On 04/30, Yury Selivanov wrote: > On 2015-04-30 1:56 PM, Ethan Furman wrote: > I still want to see where my current grammar forces to use > parens. See [1], there are no useless parens anywhere. --> await -coro() SyntaxError --> await (-coro()) # not a SyntaxError, therefore parens are

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

On 2015-04-30 1:56 PM, Ethan Furman wrote: >Why not? Unlike some other languages, Python does not have uniform >priorities for unary operators, so it's reasonable for some unary >operations to have a different priority than others, and certain things >will be SyntaxErrors because of that. E.g.

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

On 04/30, Guido van Rossum wrote: > On Thu, Apr 30, 2015 at 9:15 AM, Ethan Furman wrote: > >> [...] >> Both you and Paul are correct on this, thank you. The proper resolution >> of >> >>await -coro() >> >> is indeed to get the result of coro(), call it's __neg__ method, and then >> awa

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

On Thu, Apr 30, 2015 at 9:15 AM, Ethan Furman wrote: > [...] > Both you and Paul are correct on this, thank you. The proper resolution > of > > await -coro() > > is indeed to get the result of coro(), call it's __neg__ method, and then > await on that. > > And that is perfectly reasonable, and

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

On 04/29, Yury Selivanov wrote: > Because you want operators to be resolved in the > order you see them, generally. > > You want '(await -fut)' to: > > 1. Suspend on fut; > 2. Get the result; > 3. Negate it. > > This is a non-obvious thing. I would myself interpret it > as: > > 1. Get fut.__ne

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

On 04/29, Nathaniel Smith wrote: > (I suspect this may also be the impetus behind Greg's request that it just > be treated the same as unary minus. IMHO it matters much more that the > rules be predictable and teachable than that they allow or disallow every > weird edge case in exactly the right

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

Nathaniel Smith wrote: Even if we put aside our trained intuitions about arithmetic, I think it's correct to say that the way unary minus is parsed is: everything to the right of it that has a tighter precedence gets collected up and parsed as an expression, and then it takes that expression as i

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

On 15-04-29, Yury Selivanov wrote: > > > On 2015-04-29 3:24 PM, Isaac Schwabacher wrote: > >On 15-04-29, Yury Selivanov wrote: > >>Hi Ethan, > [..] > >>So I want to make this syntactically incorrect: > >Does this need to be a syntax error? -"hello" raises TypeError because str > >doesn't have a

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

On 15-04-29, Yury Selivanov wrote: > Hi Ethan, > > On 2015-04-29 2:32 PM, Ethan Furman wrote: > >On 04/29, Yury Selivanov wrote: > >>On 2015-04-29 1:25 PM, Ethan Furman wrote: > >>>cannot also just work and be the same as the parenthesized > >>>version. > >>Because it does not make any sense. > >

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

Yury Selivanov wrote: Sorry, but I'm not sure where & when I had any troubles predicting the consequences.. You said you wanted 'await a() * b()' to be a syntax error, but your grammar allows it. -- Greg ___ Python-Dev mailing list Python-Dev@python.

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

Nathaniel Smith wrote: (I suspect this may also be the impetus behind Greg's request that it just be treated the same as unary minus. IMHO it matters much more that the rules be predictable and teachable than that they allow or disallow every weird edge case in exactly the right way.) Exactly

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

On Wed, Apr 29, 2015 at 5:05 PM, Yury Selivanov wrote: > Nathaniel, > > On 2015-04-29 7:58 PM, Nathaniel Smith wrote: >> >> On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov >> wrote: >>> >>> Nathaniel, >>> >>> On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about >>

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

Nathaniel, On 2015-04-29 7:58 PM, Nathaniel Smith wrote: On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: Nathaniel, On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about is that whatever syntax we end up with, there should be*some* accurate human-readable descrip

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

Guido, On 2015-04-29 7:52 PM, Guido van Rossum wrote: On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: Nathaniel, On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about is that whatever syntax we end up with, there should be*some* accurate human-readable descript

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

On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: > Nathaniel, > > On 2015-04-29 7:35 PM, Nathaniel Smith wrote: >> >> What I do feel strongly about >> is that whatever syntax we end up with, there should be*some* >> accurate human-readable description of*what it is*. AFAICT the PEP >> curren

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

On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: > Nathaniel, > > On 2015-04-29 7:35 PM, Nathaniel Smith wrote: > >> What I do feel strongly about >> is that whatever syntax we end up with, there should be*some* >> accurate human-readable description of*what it is*. AFAICT the PEP >> curren

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

Nathaniel, On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about is that whatever syntax we end up with, there should be*some* accurate human-readable description of*what it is*. AFAICT the PEP currently doesn't have that. How to define human-readable description of how u

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

On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing wrote: > Yury Selivanov wrote: >> >> I'm not sure >> why Greg is pushing his Grammar idea so aggressively. > > > Because I believe that any extra complexity in the grammar > needs a very strong justification. It's complexity in the > core language, like

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

On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing wrote: > Yury Selivanov wrote: > >> I'm not sure >> why Greg is pushing his Grammar idea so aggressively. >> > > Because I believe that any extra complexity in the grammar > needs a very strong justification. It's complexity in the > core language, like

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

Greg, On 2015-04-29 6:46 PM, Greg Ewing wrote: Yury Selivanov wrote: I'm not sure why Greg is pushing his Grammar idea so aggressively. Because I believe that any extra complexity in the grammar needs a very strong justification. It's complexity in the core language, like a new keyword, so it

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

Yury Selivanov wrote: I'm not sure why Greg is pushing his Grammar idea so aggressively. Because I believe that any extra complexity in the grammar needs a very strong justification. It's complexity in the core language, like a new keyword, so it puts a burden on everyone's brain. Saying "I do

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

On 2015-04-29 3:24 PM, Isaac Schwabacher wrote: On 15-04-29, Yury Selivanov wrote: Hi Ethan, [..] So I want to make this syntactically incorrect: Does this need to be a syntax error? -"hello" raises TypeError because str doesn't have a __neg__, but there's no reason a str subclass couldn'

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

Hi Nathaniel, BTW, I'm going to reply to you in the other thread about context-local objects soon. I have some thoughts on the topic. On 2015-04-29 3:14 PM, Nathaniel Smith wrote: On Apr 29, 2015 11:49 AM, "Yury Selivanov" wrote: Hi Ethan, On 2015-04-29 2:32 PM, Ethan Furman wrote: On 04/

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

On Apr 29, 2015 11:49 AM, "Yury Selivanov" wrote: > > Hi Ethan, > > > On 2015-04-29 2:32 PM, Ethan Furman wrote: >> >> On 04/29, Yury Selivanov wrote: >>> >>> On 2015-04-29 1:25 PM, Ethan Furman wrote: cannot also just work and be the same as the parenthesized version. >>> >>> Becau

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

Hi Ethan, On 2015-04-29 2:32 PM, Ethan Furman wrote: On 04/29, Yury Selivanov wrote: On 2015-04-29 1:25 PM, Ethan Furman wrote: cannot also just work and be the same as the parenthesized version. Because it does not make any sense. I obviously don't understand your position that "it does not

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

On 29 April 2015 at 19:32, Ethan Furman wrote: > On 04/29, Yury Selivanov wrote: >> On 2015-04-29 1:25 PM, Ethan Furman wrote: >>> cannot also just work and be the same as the parenthesized >>> version. >> >> Because it does not make any sense. > > I obviously don't understand your position that "

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

On 04/29, Yury Selivanov wrote: > On 2015-04-29 1:25 PM, Ethan Furman wrote: >> cannot also just work and be the same as the parenthesized >> version. > > Because it does not make any sense. I obviously don't understand your position that "it does not make any sense" -- perhaps you could explain a

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

Ethan, On 2015-04-29 1:25 PM, Ethan Furman wrote: cannot also just work and be the same as the parenthesized version. Because it does not make any sense. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/

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

On 04/29, Yury Selivanov wrote: > On 2015-04-29 11:29 AM, Ethan Furman wrote: >> Python is not lisp, and await is not a >> function, so parens should not be needed in the common case. > > Which common case you mean? The common case of not wanting to write parenthesis. ;) Seriously, why are the

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

— Sent from Mailbox On Wednesday Apr 29, 2015 at 7:14 PM, Yury Selivanov , wrote:Also please see this: https://hg.python.org/peps/rev/d048458307b7 FWIW, 'await await fut' isn't something that you likely to see in your life; 'await -fut' is 99.999% just a bug. Agree.​ I'm not sure why G

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

Also please see this: https://hg.python.org/peps/rev/d048458307b7 FWIW, 'await await fut' isn't something that you likely to see in your life; 'await -fut' is 99.999% just a bug. I'm not sure why Greg is pushing his Grammar idea so aggressively. Yury On 2015-04-29 11:33 AM, Yury Selivanov wrot

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

Ethan, On 2015-04-29 11:29 AM, Ethan Furman wrote: Python is not lisp, and await is not a function, so parens should not be needed in the common case. Which common case you mean? Please see this table https://www.python.org/dev/peps/pep-0492/#syntax-of-await-expression Yury ___

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

On 04/29, Yury Selivanov wrote: > On 2015-04-29 5:12 AM, Greg Ewing wrote: >> 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 'fa

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

On 2015-04-29 5:12 AM, Greg Ewing wrote: 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 allow await -fut # a

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

Yury Selivanov wrote: It's just like unary minus ;) I'm confused. I thought you were arguing that your grammar is better because it's *not* just like unary minus? If being just like unary minus is okay, then why not just make it so? -- Greg ___ Pyt

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

Guido van Rossum wrote: I don't care for await await x. But do you dislike it enough to go out of your way to disallow it? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: htt

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

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 allow await -fut # await (-fut) Is there really a need to dis

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 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 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] PEP 492 vs. PEP 3152, new round

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 with parens) Yury On 2015-04-27 8:52 AM, Greg Ewing wrote: Yury Selivanov wrote:

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

Yury Selivanov wrote: I've done some experiments with grammar, and it looks like we indeed can parse await quite differently from yield. Three different options: You don't seem to have tried what I suggested, which is to make 'await' a unary operator with the same precedence as '-', i.e. replac

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

On 26 April 2015 at 06:18, Yury Selivanov wrote: > Option #3. Create a new terminal for await expression between > 'atom' and 'power'. > > Required grammar changes: > https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-3-patch > > Repo to play with (parser module is broken atm): > https:

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

+1 for option 3. On Sat, Apr 25, 2015 at 1:18 PM, Yury Selivanov wrote: > Hi Guido, > > On 2015-04-24 1:03 PM, Guido van Rossum wrote: > >> *3. syntactic priority of `await`* >> >> Yury, could you tweak the syntax for `await` so that we can write the most >> common usages without parentheses? In

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

Hi Guido, On 2015-04-24 1:03 PM, Guido van Rossum wrote: *3. syntactic priority of `await`* Yury, could you tweak the syntax for `await` so that we can write the most common usages without parentheses? In particular I'd like to be able to write ``` return await foo() with await foo() as bar: ..

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

Victor Stinner wrote: It's now time to focus our good energy on discussing remaining questions on the PEP 492 to make it the best PEP ever! That's what I'm trying to do. I just think it would be even better if it could be made to address that issue somehow. I haven't thought of a way to do that

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

2015-04-25 8:23 GMT+02:00 Greg Ewing : > But how is an awaitable supposed to raise StopIteration > if it's implemented by a generator or async def[*] function? > Those things use StopIteration to wrap return values. > > I like the idea of allowing StopIteration to be raised > in an async def functi

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

Hi Greg, 2015-04-25 7:02 GMT+02:00 Greg Ewing : >> I accept the compromise of creating a coroutine object without wait >> for it (obvious and common bug when learning asyncio). Hopefully, we >> keep the coroutine wrapper feature (ok, maybe I suggested this idea to >> Yury because I suffered so muc

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

On 25 April 2015 at 16:23, Greg Ewing wrote: > Guido van Rossum wrote: >> >> Sorry, when I wrote "future" (lower-case 'f') I really meant what Yury >> calls *awaitable*. That's either a coroutine or something with an __await__ >> emthod. > > > But how is an awaitable supposed to raise StopIteratio

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

Guido van Rossum wrote: Sorry, when I wrote "future" (lower-case 'f') I really meant what Yury calls *awaitable*. That's either a coroutine or something with an __await__ emthod. But how is an awaitable supposed to raise StopIteration if it's implemented by a generator or async def[*] function

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

On 25 April 2015 at 07:37, Łukasz Langa wrote: > On Apr 24, 2015, at 10:03 AM, Guido van Rossum wrote: > 3. syntactic priority of `await` > > Yury, could you tweak the syntax for `await` so that we can write the most > common usages without parentheses? > > +1 > > Yury points out there was likely

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

Victor Stinner wrote: That's why I suggest to reconsider the idea of supporting an *optional* "from __future__ import async" to get async and await as keywords in the current file. This import would allow all crazy syntax. The parser might suggest to use the import when it fails to parse an asyn

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

Guido van Rossum wrote: Yury, could you tweak the syntax for `await` so that we can write the most common usages without parentheses? In particular I'd like to be able to write ``` return await foo() with await foo() as bar: ... foo(await bar(), await bletch()) ``` Making 'await' a prefix ope

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

Sorry, when I wrote "future" (lower-case 'f') I really meant what Yury calls *awaitable*. That's either a coroutine or something with an __await__ emthod. On Fri, Apr 24, 2015 at 3:17 PM, Łukasz Langa wrote: > > On Apr 24, 2015, at 10:03 AM, Guido van Rossum wrote: > > *6. StopAsyncException* >

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

> On Apr 24, 2015, at 10:03 AM, Guido van Rossum wrote: > > 6. StopAsyncException > > What if we required `ait.__anext__()` to return a future? On top of my previous response, one more thing to consider is that this idea brings a builtin Future back to the proposal, which has already been rej

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

Lukasz, On 2015-04-24 5:37 PM, Łukasz Langa wrote: (Though maybe we should consider `await for` and `await with`? That would have the advantage of making it easy to scan for all suspension points by searching for /await/. But being a verb it doesn't read very well.) I’m on the fence here.

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

Hi, 2015-04-24 19:03 GMT+02:00 Guido van Rossum : > 1. precise syntax of `async def` > > Of all the places to put `async` I still like *before* the `def` the best. So do I. > 2. do we need `async for` and `async with` > > Yes we do. I agree. > 3. syntactic priority of `await` > > Yury, could

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

Victor, On 2015-04-24 5:32 PM, Victor Stinner wrote: 7. compatibility with asyncio and existing users of it The current state of the PEP makes types.coroutine() mandatory. If a generator-based coroutine is not modified with types.coroutine, await cannot be used on it. To be more concrete: async

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

> On Apr 24, 2015, at 10:03 AM, Guido van Rossum wrote: > > 1. precise syntax of `async def` > > So I still prefer `async def`. Me too. Also, we would use a similar vocabulary to existing users of the feature. This is exactly how Hack does it: http://docs.hhvm.com/manual/en/hack.async.php <

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

On Fri, Apr 24, 2015 at 11:03 AM, Ethan Furman wrote: > On 04/24, Yury Selivanov wrote: > > On 2015-04-24 1:03 PM, Guido van Rossum wrote: > > >> Ditto for `__aiter__` and `__anext__`. I guess this means that the async > >> equivalent to obtaining an iterator through `it = iter(xs)` followed by >

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

On 04/24, Yury Selivanov wrote: > On 2015-04-24 1:03 PM, Guido van Rossum wrote: >> Ditto for `__aiter__` and `__anext__`. I guess this means that the async >> equivalent to obtaining an iterator through `it = iter(xs)` followed by >> `for x over it` will have to look like `ait = await aiter(xs)`

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

Guido, On 2015-04-24 1:03 PM, Guido van Rossum wrote: *3. syntactic priority of `await`* Yury, could you tweak the syntax for `await` so that we can write the most common usages without parentheses? In particular I'd like to be able to write ``` return await foo() with await foo() as bar: ...

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

I've tried to catch up with the previous threads. A summary of issues brought up: 1. precise syntax of `async def` (or do we need it at all) 2. do we need `async for` and `async with` (and how to spell them) 3. syntactic priority of `await` 4. `cocall` vs. `await` 5. do we really need `__aiter__`