Use standalone result library instead

[Fuyukai]

As said in #477, the Result objects got split out into a separate library (https://github.com/python-trio/outcome). There's no point duplicating all the code in Trio - better to depend on it directly.

Todo:

• Gut result code inside of Trio
• Use the results from outcome instead.

Maybe make the current objects in Trio simply redirect to the outcome objects until the next version, deprecating them in 0.5 (with a redirect) and removing in 0.6.

[njsmith]

CC @RazerM

There may be a small bit of awkwardness here because outcome also tweaked the API: Result.capture got replaced with outcome.capture instead of outcome.Outcome.capture. This is probably a good change on its own merits (the only reason I stuck capture onto the Result type was because I didn't have a proper module to put it on), but it means we can't just alias Result to outcome.Outcome and have everything work. The simplest thing might be to do:

class Result(Outcome):
    @classmethod
    def capture(...):
        ...

    @classmethod(...)
    async def acapture(...):
        ...

Result.register(Outcome)  # yes, they're subclasses of each other, what's wrong with that?

Gross hacks are fine because it's just a temporary shim that we'll throw away in a few versions after the deprecation period...

[RazerM]

@njsmith We'll have a problem there from

https://github.com/python/cpython/blob/1672c2fbae6128ee4717e08c4e65a0ab99a02a02/Lib/abc.py#L162-L164

[njsmith]

Bah, fine. I bet CPython isn't any fun at parties either.

In this case I think it would be enough to register just the concrete classes outcome.Value and outcome.Error.

[Fuyukai]

The issue with this is that I cannot see a way to meet all of the following:

• Keep the same API (i.e. capture/acapture) for all types
• Make isinstance() work properly with both outcome and _core._result types

If the first point is lifted, it can simply be Value = outcome.Value / Error = outcome.Error and register them as virtual subclasses of Result.

[njsmith]

Oh, you mean because right now someone could write Value.capture(...), and that would break if we do Value = outcome.Value? I guess that's technically true, but I doubt anyone's ever done that and I'm fine with just ignoring it. So I think I'm agreeing with your suggestion.