Yury Selivanov <[email protected]> added the comment:
First, I've no questions about the proposed implementation. It shouldn't have
performance impact when unawaited coroutine tracking is off, which is the
default. It will cause minimal overhead when the tracking is on, which is
fine. Adding two extra pointers to coroutine objects should be OK too.
Back to the specification. Few questions:
1. How will trio handle situations like:
c = coro()
await ...
nursery.start_soon(c)
?
There's a brief period of time when "c" is not being awaited, and thus it will
be in the list that "sys.collect_unawaited_coroutines()" returns. How exactly
do you plan to use this new API in Trio?
Maybe creating a coroutine and not immediately passing it to 'start_soon' or
similar API is an anti-pattern in Trio, but it is an OK thing to do in
asyncio/curio/twisted.
2. What if another framework (say asyncio that you want to interoperate with)
calls "sys.set_unawaited_coroutine_tracking(False)"?
The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()'
has, when used by several frameworks simultaneously.
3. Given (2), why don't you have a coroutine wrapper like this:
def trio_coroutine_wrapper(coro):
ref = weakref.ref(coro, trio._untrack_coro)
trio._track_coro(ref)
return coro
This way:
- you don't introduce a lot of overhead, because there's no actual wrapper
around a coroutine
- you can capture the file/lineno at the point where a coroutine was created,
which is useful for reporting unawaited coroutines
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue30491>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
