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

Decide where to use trio._util.Final #1044

Open
njsmith opened this issue May 7, 2019 · 4 comments

Comments

@njsmith
Copy link
Member

commented May 7, 2019

Possibly we should use it on... all classes? (Except ABCs.) Possibly not.

@njsmith

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

From a quick skim, here are some classes that should probably be marked NoPublicConstructor:

  • Task
  • TrioToken
  • Nursery (PR at #1090)
  • memory channels (though they need to be refactored in general, and need #1092 to be sorted out first)

For Final... I'm actually serious that it should potentially be used for every single public class in Trio, outside of trio.abc. There are a very small number of places where we use inheritance ourselves (StrictFIFOLock), but in general Trio doesn't use subclassing and its classes haven't been designed with any consideration for subclassing.

@njsmith

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2019

This is some kind of argument, but I'm not sure if it's for or against :-)

https://trio.discourse.group/t/socketstream-putback/208/8?u=njs

@belm0

This comment has been minimized.

Copy link
Member

commented Aug 30, 2019

MultiError? #1199

@njsmith

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2019

@belm0 yeah I thought about bringing this up in #1199, but decided there wasn't any point. MultiError is going to get killed once exceptiongroup is ready, so there's no point in messing around with it too much, and IIUC anyio's subclassing is just a workaround for exceptiongroup not being ready yet anyway; no point in making @agronholm's life difficult by outlawing his temporary workaround. And I think exceptiongroup will have to allow subclassing because Yury wants to make an empty subclass class AsyncioExceptionGroup(ExceptionGroup, Exception) as a partial workaround for try/except not being exception-group-aware. For the eventual PEP version we might be able to switch it back to no-subclasses though, depending on what happens with try/except.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.