Re: [Python-ideas] PEP 525: Asynchronous Generators

Hi Yury et al, Apologies for not participating in this discussion before -- unfortunately I've been dealing with some boring medical issues and haven't been able to contribute as much as early as I should have... But I do have two concerns, one minor and one not. Minor comment: this is purely an

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 2016-08-16 12:46 PM, Moritz Sichert via Python-ideas wrote: 2. It's extremely unlikely that somebody will design a system that switches coroutine runners *while async/awaiting a coroutine*. Yes, I guess so. But even in this unlikely use case, you can easily stack finalizers following this

Re: [Python-ideas] PEP 525: Asynchronous Generators

>>> 2. It's extremely unlikely that somebody will design a system that >>> switches coroutine runners *while async/awaiting a coroutine*. >> Yes, I guess so. >> >> >>> But even in this unlikely use case, you can >>> easily stack finalizers following this pattern: >>> >>>old_finalizer = sys.get_

Re: [Python-ideas] PEP 525: Asynchronous Generators

> On 11 Aug 2016, at 16:22, Thomas Güttler wrote: > > The user there writes: [about await] That sounds quite like Cooperative > multitasking to me. > > In 1996 I was a student at university and was told that preemptive > multitasking is better. > > Since tools like http://python-rq.org/ can

Re: [Python-ideas] PEP 525: Asynchronous Generators

Am 10.08.2016 um 19:17 schrieb Sven R. Kunze: On 09.08.2016 05:23, Nick Coghlan wrote: On 9 August 2016 at 08:37, Sven R. Kunze mailto:srku...@mail.de>> wrote: From what I've heard in the wild, that most if not all pieces of async are mirroring existing Python features. So, building

Re: [Python-ideas] PEP 525: Asynchronous Generators

> On 11 Aug 2016, at 13:00, Nick Coghlan wrote: > Twisted callbacks are still red functions - you call them via the event loop > rather than directly, and only event loop aware functions know how to make > that request of the event loop. > > async/await just makes the function colour locally v

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 11 Aug 2016 18:48, "Cory Benfield" wrote: > > While we’re talking about function colour, we should note that you don’t *have* to have function colour. A quick look at your average Twisted codebase that doesn’t use @inlineCallbacks will quickly show you that you can write an asynchronous program

Re: [Python-ideas] PEP 525: Asynchronous Generators

> On 11 Aug 2016, at 04:46, Chris Angelico wrote: > > Though tongue-in-cheek, this talk shows (along the way) some of the > costs of preemption, and thus some of the possibilities you'd open up > if you could go back to cooperation. While I don't think the time is > right for *operating systems*

Re: [Python-ideas] PEP 525: Asynchronous Generators

On Thu, Aug 11, 2016 at 1:17 PM, Nick Coghlan wrote: >> Lately, I talked to friend of mine about async and his initial reaction >> was like "hmm that reminds me of early programming days, where you have to >> explicitly tell the scheduler to get control back". He's much older than me, >> so I thin

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 11 August 2016 at 03:17, Sven R. Kunze wrote: > On 09.08.2016 05:23, Nick Coghlan wrote: > > On 9 August 2016 at 08:37, Sven R. Kunze wrote: > >> From what I've heard in the wild, that most if not all pieces of async >> are mirroring existing Python features. So, building async basically buil

Re: [Python-ideas] PEP 525: Asynchronous Generators

I think over on async-sig my confusion over how this is for async generators and not coroutines came up. Now I think I know where my confusion stems from. I don't think this will change anything, but I wanted to get it out there as it might influence how we communicate things. Take Yury's simple e

Re: [Python-ideas] PEP 525: Asynchronous Generators

On Thu, Aug 11, 2016 at 3:17 AM, Sven R. Kunze wrote: > Lately, I talked to friend of mine about async and his initial reaction was > like "hmm that reminds me of early programming days, where you have to > explicitly tell the scheduler to get control back". He's much older than me, > so I think i

Re: [Python-ideas] PEP 525: Asynchronous Generators

Hi Brett, On 2016-08-10 12:27 PM, Brett Cannon wrote: [..] According to the inspect module that's a coroutine function that creates a coroutine/awaitable (and a function w/ @types.coroutine is just an awaitable when it contains a `yield`). Now the existence of `yield` in a function causing i

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 09.08.2016 05:23, Nick Coghlan wrote: On 9 August 2016 at 08:37, Sven R. Kunze > wrote: From what I've heard in the wild, that most if not all pieces of async are mirroring existing Python features. So, building async basically builds a parallel structure i

Re: [Python-ideas] PEP 525: Asynchronous Generators

Hi Vladimir, On 2016-08-09 1:24 PM, Vladimir Rutsky wrote: Hi Yury, Thank you for posting this PEP! As an asyncio-based libraries user, author and contributor I appreciate that topic of easy-writing of asynchronous generators is being covered now. I like how simple writing of async generators

Re: [Python-ideas] PEP 525: Asynchronous Generators

Hi Yury, Thank you for posting this PEP! As an asyncio-based libraries user, author and contributor I appreciate that topic of easy-writing of asynchronous generators is being covered now. I like how simple writing of async generators will be with this PEP, same with consequent functionality (e.g.

Re: [Python-ideas] PEP 525: Asynchronous Generators

On Tue, Aug 9, 2016 at 7:13 AM, Nick Coghlan wrote: > > On 9 August 2016 at 13:27, Guido van Rossum wrote: > >> Just don't oversell run_until_complete() -- some people coming from >> slightly different event loop paradigms expect to be able to pump for >> events at any point, possibly causing re

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 2016-08-09 10:18 AM, Adam Bartoš wrote: [..] I understand that having the concepts truly ortogonal would mean tons of work, I just think it's pity that something natural doesn't work only because of implementation reasons. However, introducing async generators is an important step in the r

Re: [Python-ideas] PEP 525: Asynchronous Generators

Hello, when I was reading the PEP, it surprised me that return is not allowed in an async generator. You can transparently decompose an ordinary function, and yield from was added to be able to do the same with generators, so it seems natural to be able to decompose async generators the same way –

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 9 August 2016 at 13:27, Guido van Rossum wrote: > Just don't oversell run_until_complete() -- some people coming from > slightly different event loop paradigms expect to be able to pump for > events at any point, possibly causing recursive invocations. That doesn't > work here (and it's a feat

Re: [Python-ideas] PEP 525: Asynchronous Generators

Just don't oversell run_until_complete() -- some people coming from slightly different event loop paradigms expect to be able to pump for events at any point, possibly causing recursive invocations. That doesn't work here (and it's a feature it doesn't). On Mon, Aug 8, 2016 at 8:23 PM, Nick Coghla

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 9 August 2016 at 08:37, Sven R. Kunze wrote: > From what I've heard in the wild, that most if not all pieces of async are > mirroring existing Python features. So, building async basically builds a > parallel structure in Python resembling Python. Async generators complete > the picture. Some

Re: [Python-ideas] PEP 525: Asynchronous Generators

On 08.08.2016 19:06, Yury Selivanov wrote: You have to be aware of what you're decorating. Always. You have to be aware of what the decorator does first before you decide if it's relevant to be aware of what you're decorating. For instance, here's an example of a buggy code: @functools.lru