Hacker News new | ask | show | jobs
by petters 2115 days ago
Hmm, so you're saying that this library is not really needed? I'll look into this.
2 comments

Hi, author here,

While yes, running a coroutine in a new task is in the standard library, that is only a component of what this library does, which is:

- given an async iterable,

- iterating over it in a new task, into a buffer,

- and then returning an iterable that yields values from this buffer as it's filled.

I don't _think_ this logic is in the standard library, at least not at https://docs.python.org/3/library/asyncio-task.html#asyncio.... from what I can see.

Yeah, this actually looks pretty cool, it's a nice way to abstract a common pattern which is otherwise quite tedious, namely, that of spawning a bunch of tasks and have them feed each other work via asyncio queues.

Have you thought about making it work as a decorator?

Indirectly: the initial version was a single function, so could have been used in a decorator easily enough.

The issue is what happens on exceptions to avoid tasks hanging around forever. Exceptions propagate “forward” in the pipeline fairly automatically. However, getting the ones “behind” the exception to notice: that was tricky. The best I came up with was the bit of state wrapped up in buffered_pipeline that notices the exceptions and cancels the tasks.

I'm not saying the OP code isn't useful, but I do think that readers may be unaware of existing documented features and jumping into a library to solve their perceived problems is short changing the existing mechanisms.

I've gotten along ok with create_task and gather. I'll need to spend some time with this implementation to see if it fits any of my existing asyncio coding patterns.