Joshua Oreman

That makes sense, but it seems resolvable to me? Tracebacks are basically immutable once created; raising an exception adds new frames and modifies `__traceback__` to point to the new head...

Update on this: `trio-typing` is now a real package that people other than me appear to be using. I'm interested in adding the type hints to Trio proper at some...

As mentioned in #778, adding type hints will require us to publicize some important types like `Nursery` and `TaskStatus`. This requires guarding them better against instantiation/subclassing (#1021). Alternatively, we could...

I like this. @njsmith thoughts? I often find myself wanting a single object that includes both ends of the channel, like the old `trio.Queue`. With this PR I can now...

I think we should try harder to make this backwards-compatible. The big benefit of ExceptionGroups (`except*` syntax) will not be available to basically any of our users for ~10 more...

It's pretty hard to construct a MultiError without writing the name `trio.MultiError`. If we raise a deprecation warning when the name is accessed, I don't think we need another one...

I mean that this construct ``` enable_attribute_deprecations(__name__) __deprecated_attributes__ = {"MultiError": DeprecatedAttribute(_MultiError, ...)} ``` causes a deprecation warning to be raised at the point where someone writes `trio.MultiError`, regardless of whether...

I figure since we already have the explicit facility we may as well use it, but I guess a module-level `__getattr__` works too.

Thank you for working on this! We should have some tests that actually use `except*` on 3.11. Ideally we could rewrite them (maybe automatically?) to use `with catch()` on

I don't know if I'd say that a *lot* of libraries would need it, but I think it's a feature that will be useful to libraries in at least some...