![](https://secure.gravatar.com/avatar/61a537f7b31ecf682e3269ea04056e94.jpg?s=120&d=mm&r=g)
On 2012-10-23, at 7:00 PM, Sam Rushing <sam-pydeas@rushing.nightmare.com> wrote:
On 10/23/12 3:05 PM, Yury Selivanov wrote:
Sam,
BTW, kudos for shrapnel! Thanks!
For basic library functions that will work. And that's already a huge win. But developing a complicated library will become twice as hard, as you'll need to maintain two versions of API - sync & async all the way through the code.
This is really difficult, if you want to see a great example of trying to make all parties happy, look at Pika (an AMQP implementation).
Thanks, will take a look!
Actually this reminds me, it would be really great if there was a standardized with_timeout()API. It's better than adding timeout args to all the functions. I'm sure that systems like Twisted & gevent could also implement it (if they don't already have it):
In shrapnel it is simply:
coro.with_timeout (<seconds>, <fun>, *args, **kwargs)
Timeouts are caught thus:
try: coro.with_timeout (...) except coro.TimeoutError: ...
You're right--if we want to ship some "standard" async API in python, API for timeouts is a must. We will at least need to handle timeouts in async code in the stdlib, won't we... A question: How do you protect finally statements in shrapnel? If we have a following coroutine (greenlet style): def foo(): connection = open_connection() try: spam() finally: [some code] connection.close() What happens if you run 'foo.with_timeout(1)' and timeout occurs at "[some code]" point? Will you just abort 'foo', possibly preventing 'connection' from being closed? - Yury