Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use standalone result library instead #494

Closed
2 tasks done
Fuyukai opened this issue Apr 14, 2018 · 5 comments
Closed
2 tasks done

Use standalone result library instead #494

Fuyukai opened this issue Apr 14, 2018 · 5 comments

Comments

@Fuyukai
Copy link
Member

Fuyukai commented Apr 14, 2018

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
Copy link
Member

njsmith commented Apr 14, 2018

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
Copy link
Member

RazerM commented Apr 14, 2018

@njsmith
Copy link
Member

njsmith commented Apr 15, 2018

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
Copy link
Member Author

Fuyukai commented Apr 15, 2018

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
Copy link
Member

njsmith commented Apr 15, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants