A5rocks

I think allowing subclassing is conceptually the wrong approach. 1) NEVERMIND, I accidentally read "sync context manager" as "sync iterator". My objections don't hold for it, though IMO (3) still...

I'm not sure whether returning a `MemoryReceiveChannel` is necessary: - if using a type checker, you could make a protocol of the things you like on `MemoryReceiveChannel` and return that...

That may be a better idea, especially if we decide not to match the interface of the latter! I think the logic goes: memory receive channels need a memory send...

I mentioned `.clone()` because it was removed from `ReceiveChannel`'s public API. Specifically referencing https://github.com/python-trio/trio/pull/1115 which was informed by https://github.com/python-trio/trio/issues/719. Concrete proposal: there's a `BufferingReceiveChannel` (naming is hard...) that inherits `ReceiveChannel`...

> I've got couple of questions. - version should be the next Trio version. Since we're including a deprecation, this is a "minor" change, it's 0.32.0. - personally I think...

I think the deprecation should go in `trio.testing`? I'm probably misunderstanding what you're saying cause it sounds like you tried that...

Note that this is how the usage looks like (it's a bit complicated because you need the actual underlying object, but under a different name) ```py deprecate_attributes(__name__, { "RaisesGroup": DeprecatedAttribute(_RaisesGroup,...

@AbduazizZiyodov I might be misunderstanding things but: 1. maybe just deprecate it? we don't need to provide a direct translation to pytest. (I think the direct translation is `RaisesExc`, though)...

@AbduazizZiyodov just bumping since it would be nice to get this by the next release. (which will be... I don't know yet, maybe New Year's would be a nice time?)

Looks like this would require changes in https://github.com/python-trio/sphinxcontrib-trio. Feel free to renovate the CI! (probably also request a review from me, since I don't think I get notifications from that...