Re: [Python-Dev] A more flexible task creation

How about: async def wait_to_run(async_fn, *args): await wait_for_something() return await async_fn(*args) task = loop.create_task(wait_to_run(myfunc, ...)) - Whatever strategy you use, you should also think about what semantics you want if one of these delayed tasks is cancelled be

Re: [Python-Dev] A more flexible task creation

On Wed, Jun 13, 2018 at 4:47 PM Michel Desmoulin wrote: > > I was working on a concurrency limiting code for asyncio, so the user > may submit as many tasks as one wants, but only a max number of tasks > will be submitted to the event loop at the same time. What does that "concurrency limiting co

[Python-Dev] A more flexible task creation

I was working on a concurrency limiting code for asyncio, so the user may submit as many tasks as one wants, but only a max number of tasks will be submitted to the event loop at the same time. However, I wanted that passing an awaitable would always return a task, no matter if the task was curren

Re: [Python-Dev] Some data points for the "annual release cadence" concept

> On 13 Jun 2018, at 15:42, Nick Coghlan wrote: > > On 13 June 2018 at 02:23, Guido van Rossum > wrote: > So, to summarize, we need something like six for C? > > Yeah, pretty much - once we can get to the point where it's routine for folks > to be building "abiX" or

Re: [Python-Dev] Some data points for the "annual release cadence" concept

On 13 June 2018 at 02:23, Guido van Rossum wrote: > So, to summarize, we need something like six for C? > Yeah, pretty much - once we can get to the point where it's routine for folks to be building "abiX" or "abiXY" wheels (with the latter not actually being a defined compatibility tag yet, but

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 b

On 13 June 2018 at 04:47, Mariatta Wijaya wrote: > Backing up GitHub data has been brought up since the time we migrated to > GitHub, and being tracked here: https://github.com/pytho > n/core-workflow/issues/20 > > TL;DR We'll be using GitHub's new Migrations API >

Re: [Python-Dev] Some data points for the "annual release cadence" concept

On 12.06.2018 14:38, Nick Coghlan wrote: Since we last seriously discussed potential release cadence changes back in 2012 (with PEPs 407 and 413 [2,3]), that means JEE joins GCC switching to an annual release cadence from GCC 5 back in 2015 (see [4]), no, GCC is doing yearly releases since 2001

Re: [Python-Dev] Some data points for the "annual release cadence" concept

On 12.06.2018 18:23, Guido van Rossum wrote: So, to summarize, we need something like six for C? there is https://github.com/encukou/py3c ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe