# An eager way to set\_result on asyncio.Future?

**URL:** <https://discuss.python.org/t/an-eager-way-to-set-result-on-asyncio-future/106161>\
**Category:** Async-SIG\
**Tags:** asyncio\
**Created:** [February 15, 2026, 7:12am UTC](https://discuss.python.org/t/an-eager-way-to-set-result-on-asyncio-future/106161 "2026-02-15T07:12:09Z")\
**Posts on this page:** 1\
**Showing post:** 27

<div class="post-metadata">

**Author:** ![Tinche](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tinche/32/12507_2.png) [@Tinche](https://discuss.python.org/u/Tinche)\
**Post date:** [February 20, 2026, 2:58pm UTC](https://discuss.python.org/t/an-eager-way-to-set-result-on-asyncio-future/106161/27 "2026-02-20T14:58:28Z")

</div>

First of all, I think optimizing the loop or giving users knobs to tweak is much, much better than implementing new APIs that live right on the edge of allowed behavior. We keep code more understandable and potentially benefit more users.

Tweaking loop scheduling is tricky. I’d be in favor of your change, but maybe we can expose some knobs and let the users tweak the behavior and tresholds? That way if we degrade someone’s workflow, they at least have a way to restore old behavior. Some people might want even more aggressive thresholds.

---

_[View the full topic](https://discuss.python.org/t/an-eager-way-to-set-result-on-asyncio-future/106161)._