Enhancement request: Another approach to a Trionic future interface

[bob1de]

Hi,

A number of previous issues and discussions have shown that there seems to be demand for a pattern for awaiting deferred results. However, it's not clear how this could fit into Trio's structured concurrency model w.r.t. cancellation and exception handling.

Since I needed this for a project, I implemented an interface which I hope can overcome past concerns.

There's a FutureABC defining the consumer side interface (awaiting + completion status + result), so we have a well-defined interface for future-like objects, no matter how they acquire their result.
Based on that, there are two implementations:

• SyncFuture, which basically is an event and a value, so can be set synchronously.

• AsyncFuture, which bundles CancelScope + Event + Outcome, allowing a task to be cancelled, awaited and capturing its outcome, without manual with/try/except/finally nesting and the juggling of three objects. However, in contrast to the other approaches I've seen so far (incl. trio-future), it has selective exception catching (incl. ExceptionGroup splitting), so faulty code doesn't go unnoticed and whichever nursery runs the future will get any uncaught exceptions.

I'd be very interested in the experts' opinions on the concept.
At least to me the idea and API have proven to be useful, and it has clear semantics w.r.t. cancellation and exception handling.
Given the overall ABC interface finds appreciation, these might be candidates for trio._sync.

Here's the code. That file contains more than just the future implementation (maybe for later discussion), so the objects I'm talking about are FutureABC, SyncFuture and AsyncFuture. All of them are documented so far, help() should get you started.

Thanks for your time!

Relevant past issues

• Discussion on futures in Trio in general: Awaiting futures versus starting coroutines (How opinionated is trio?) #892
• A task class especially targeting the async case: Enhancement request: Task class groove-x/trio-util#20

[bob1de]

Just an addition: In a previous version, I had FutureABC being more generic and accepting any type of result, but I think directly restricting it to Outcome more appropriately targets the case of a future and makes users more aware of how they use it... though I'm open for debate.