== Context

1. Andrew and I implemented a new streaming API in asyncio 3.8.  The key idea is that there's a single Stream object, combining old StreamReader & StreamWriter APIs.  On top of that, `Stream.write()` and `Stream.close()` became coroutines.  The new API is significantly easier to use, but it required us to:

(a) Make backwards compatible changes to subprocess APIs;
(b) Add two new APIs: `asyncio.connect() -> Stream` and `asyncio.StreamServer`
(c) Soft-deprecate `asyncio.open_connection()` and `asyncio.start_serving()`.


2. The Trio project considers implementing new Streams API (see [1]).  The key idea is to make the core Stream object very simple and then enable building complex protocol pipelines using composition.  Want SSL?  Add an SSL layer.  Have a framed binary protocol?  Push a reusable framing layer to the stack and parse the protocol.  On top of that, Trio wants us to standardize Streams, so that it's possible to write framework agnostic protocol code using async/await and to even reuse things like SSL implementation.


== Problem

I really like how Trio approaches this.

The asyncio.Stream class we have now is overloaded with functionality.  It's not composable.  It's internal buffer and APIs are designed to parsing text protocols (i.e. parsing a complex binary protocol requires an entirely different buffer implementation).

Long story short, I think we should revert the new streaming API from the 3.8 branch and see if Trio & asyncio can design a better Streaming API.  Otherwise we end up in a weird situation where we added a bunch of new APIs to 3.8 which can be deprecated in 3.9.

Worst case scenario we'll just ship our current versions of Streams in 3.9 (not in 3.8).

Thoughts?

[1] https://github.com/python-trio/trio/issues/1208