John Belmonte

Since the ergonomics of concurrent exceptions were so awful, we quickly learned to avoid raising exceptions (those expected to be handled) from async API's. In the few cases where we...

> How would you feel about adding send() and receive() methods as aliases for send_channel.send() and receive_channel.receive(), plus or minus _nowait? It seems confusing for API users as it's adding...

As a straw man, here are some of the queue-like methods: ```python3 async def send(self, value): await self.send_channel.send(value) def send_nowait(self, value): self.send_channel.send_nowait(value) async def receive(self): return await self.receive_channel.receive() def receive_nowait(self):...

So what is `StapledChannel`? Is it just a named tuple, or does it have the send/receive convenience methods (https://github.com/python-trio/trio/pull/1771#issuecomment-716304932), receive async iter, and aclose?

> It would be the equivalent of `trio.StapledStream`, but for channels. So yeah, it would have all the channel methods. Would it be OK for the instance `__aiter__` to iterate...

> But, if we make memory channels symmetric like that, then it conflicts with the .send_channel/.receive_channel names proposed in this pr. Doesn't `StapledStream` use .send_stream/.receive_stream?

> Also, I feel like it will just be easier to read code where the channels are named based on the endpoint, rather than based on directionality. > > But,...

attempted `StapledMemoryChannel` in #1784 in my case I'm needing the `_nowait` variants, which aren't currently represented by any interface

@njsmith please take a look I started with StapledMemoryChannel rather than StapledChannel, since my use case is needing the nowait methods. Not sure whether it's worth making a MemoryChannel abc.

Selecting some hard-coded threshold sounds... not suitable for the variety of computers _x_ environments in the present and future? I'd like to be able to run some blessed calibration code...