gh-92679: Clarify roles of asyncio protocols and transports #92680
Conversation
|
@1st1 Could you review and possibly merge please? |
There was a problem hiding this comment.
TBH I'm not convinced that this rewrite makes the matter all that much clearer to someone who doesn't already know what Protocols and Transports are.
FWIW, we didn't invent the terminology, we borrowed it from Twisted. I can never remember what they are until I see some source code -- then it falls in place easily. The second paragraph of the original, which you ruthlessly deleted, actually explains it rather clearly. You may object that it doesn't allow for a protocol/transport pair to be inserted between another transport/protocol pair, like middleware, e.g. start_tls. But the point of middleware (in this sense) is that it doesn't matter whether the "other end" is literally what you think it is (the application or the network, depending on which side you are standing), since it's always in fact some kind of abstraction. As long as it conforms to the right interface.
| is an abstraction for an application, from the transport's point | ||
| of view. | ||
| The protocol object may either generate and consume data by its own (like a | ||
| fallback background sender behind :func:`~asyncio.loop.sendfile`), be an |
There was a problem hiding this comment.
I have no idea what a "fallback background sender" would be or why sendfile is used here. I suppose I could look it up in the source, but that's asking a bit much in a section labeled "Introduction". It should speak for itself.
There was a problem hiding this comment.
I'm sorry for postponing the stuff for so long. I've got a load of thesis work in the university so I'll be free and able to address all the comments a couple of weeks later.
There was a problem hiding this comment.
Okay, I am patiently waiting.
| Yet another view is the transport and protocol interfaces | ||
| together define an abstract interface for using network I/O and | ||
| interprocess I/O. | ||
| While the transport is actively puppeteered by an asyncio event loop, the |
There was a problem hiding this comment.
"puppeteered" is a bit poetic for technical documentation. :-)
|
The issue #92679 is closed, is this still relevant? @arhadthedev |
|
@kumaraditya303 I believe it is. The issue had a greater scope of serious rehaul found to be worth a proper pypi library for real-world testing. |
Co-authored-by: Guido van Rossum <[email protected]>
Okay thanks! I believe Guido will review this better than me so leaving this to him. |
For a year, I've seen no evidence of the contrary so closing this PR. |
#92679
cc @1st1 @asvetlov as asyncio experts.
asyncioAPI in a backward compatible manner #92679