-
-
Notifications
You must be signed in to change notification settings - Fork 348
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
AssertionError from MultiError.__init__() #1199
Comments
When And here is the value of the
|
So it's related to anyio exception groups. The base class Hmm, I see in anyio head some hack for Trio 0.12 to turn around and delete the attribute. quite a mess all around... |
I tried anyio HEAD.
So it's to do with multiple inheritance and MultiError? |
I definitely haven't thought through how to support subclassing on |
Are we sure that MultiError worked correctly in the face of subclassing / multiple inheritance even prior to that change? |
Well, at least it was fine in anyio as far as I can tell. |
@belm0 tell me again, how are you triggering the problem on the latest master version of anyio? The test suite passes just fine. |
It's a non-trivial app, I can't offer a repro at this point. I'm sure that the behavior is different between anyio 1.0.0 and head, yet the latter is not sufficient. From the debugging I did above, I think we can conclude that with subclassing and/or multiple inheritance there are other paths where |
Are you by any chance serializing the MultiErrors, possibly via multiprocessing? |
I guess not. But can you at least find out what exactly is being passed to TrioExceptionGroup's constructor? |
Sorry, operator error here. Indeed, there is not an AssertionError from Trio with anyio HEAD. So outstanding is to decide on policy about MultiError inheritance, and whether to make the internals less fragile. |
Closing this because we've dropped MultiError. |
seen in Trio 0.12.1
The text was updated successfully, but these errors were encountered: