Document streams

[asvetlov]

Explicitly document streaming API.

Fixes #1106

Also don't inherit aiohttp.StreamReader from asyncio.StreamReader.

The inheritance makes a mess.

For example asyncio.StreamReader has readuntil() method but calling it from aiohttp.StreamReader leads to crash because internal implementation differs.

[codecov-io]

Current coverage is 98.30% (diff: 100%)

Merging #1150 into master will increase coverage by 0.01%

@@             master      #1150   diff @@
==========================================
  Files            28         28          
  Lines          6489       6490     +1   
  Methods           0          0          
  Messages          0          0          
  Branches       1087       1087          
==========================================
+ Hits           6378       6380     +2   
+ Misses           61         60     -1   
  Partials         50         50          

Powered by Codecov. Last update 34c3647...1eb8110

[fafhrd91]

there was reason for inheritance. when i added inheritance asyncio did check isinstance(..., StreamReader). i don't know if it still in place

[asvetlov]

There are two checks for StreamReader in client API.
Now both are relaxed to accept asyncio.StreamReader as well as aiohttp.StreamReader explicitly as request's BODY.
I expect no backward compatibility issues.

[fafhrd91]

It is opossite, asyncio does not accept anything except asyncio.StreamReader

[asvetlov]

Got it.
@fafhrd91 what asyncio API call does accept asyncio.StreamReader only?
And why do we need these call?
I've grepped over asyncio source and have found nothing.

[fafhrd91]

asyncio still checks for StreamReader instance in streams.StreamWriter.__init__

this change will break all installations.

[asvetlov]

Yes, is has the check.
But what is your use case?
User very unlikely creates asyncio.StreamWriter manually (I mean direct writer = asyncio.StreamWriter(transport, protocol, reader, loop)) with passing aiohttp.StreamReader instance.
He uses either asyncio.open_connection() or aiohttp API.

[fafhrd91]

Ok, I am fine with change

Sent from my iPhone

On Sep 11, 2016, at 10:40 AM, Andrew Svetlov notifications@github.com wrote:

Yes, is has the check.
But what is your use case?
User very unlikely creates asyncio.StreamWriter manually (I mean direct writer = asyncio.StreamWriter(transport, protocol, reader, loop)) with passing aiohttp.StreamReader instance.
He uses either asyncio.open_connection() or aiohttp API.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[asvetlov]

@fafhrd91 thanks.
IIRC we've added overloaded aiohttp.StreamWriter later for solving another issue but now we really don't need to inherit from asyncio.StreamReader.

Honestly I feel the current aiohttp state (parsers-readers-writers-DataQueue) is messy.

Right now I have no proposal for fixing it but want to invest a time into.

I'm considering all mentioned parts as very deep implementation details, e.g. if we'll drop DataQueue but incorporate processing into aiohttp.StreamWriter with keeping existing functionality nothing will fail, isn't it?

P.S.
The proposed change is not a subject for next release.