Is the assert still there? Maybe someone should just submit a PR with a
fix? (Although it's too late for 3.6.0, it may make it into 3.6.1 since it
feels like a bugfix to me.)

On Tue, Nov 29, 2016 at 8:01 AM, Mathias Fröjdman <> wrote:

> On Monday, June 15, 2015 at 10:49:28 PM UTC+3, Guido van Rossum wrote:
>> Fair enough. I guess there is a real danger to overwhelm the socket?
>> Otherwise you don't even need the drain() call. But it looks like you are
>> basically logging as fast as you can, so the drain() seems important.
> I still think that this is a relatively rare case and I don't want to
>> encourage sharing streams between coroutines. Maybe you can submit a patch
>> to turn the assert into a RuntimeError?
> My 5c: I'm writing an AMQP client library. The AMQP protocol consists of a
> sequence of frames, which may (mostly) be interleaved. I use
> StreamWriter.drain() before sending large frames to make sure I'm not
> flooding the write buffer. I ran into this AssertionError while testing
> publishing messages from multiple tasks works - it didn't. Thinking there's
> some inherent reason drain() must be called from only one task, I started
> figuring out what logic I need to determine when to call it with the
> assumption it returns only when the buffer is empty. Instead it turns out
> it has water marks and the works, so I just wrapped the call in async with
> an asyncio.Lock.
> I'm not sure the AssertionError is more help than harm, as protocols such
> as this one where several tasks may operate on the same protocol just need
> to work around it, and protocols that don't support interleaving of writes
> probably run into bugs anyway.
> --
> Mathias

--Guido van Rossum (

Reply via email to