[Python-ideas] The async API of the future: Reactors

[Guido van Rossum]

On Mon, Oct 15, 2012 at 8:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Oct 16, 2012 at 1:33 AM, Guido van Rossum <guido at python.org> wrote:
>> But you're still stuck with implementing the names that someone else
>> decided upon a decade ago... :-)
>
> There's a certain benefit to everyone using the same names and being
> able to read each others code, even when there's a (small?) risk of
> the names not aging well. Do we really want the first step in
> deciphering someone else's async code to be "OK, what did they call
> their connection and data processing callbacks?"?
>
> Twisted's IProtocol API is pretty simple:
> - makeConnection
> - connectionMade
> - dataReceived
> - connectionLost
>
> Everything else is up to the individual protocols (including whether
> or not they offer a "write" method)
>
> The transport and producer/consumer APIs aren't much more complicated
> (https://twistedmatrix.com/documents/current/core/howto/producers.html)
> and make rather a lot of sense. The precise *shape* of those APIs are
> likely to be different in a generator based system, and I assume we'd
> want to lose the camel-case names, but standardising the terminology
> seems like a good idea.

I guess you see it as a template pattern, where everybody has to
implement the same state machine *somehow*. Like having to implement a
file-like object, or a mapping. I'm still convinced that the alternate
POV is just as valid in this case, but I'm going to let it rest
because it doesn't matter enough to me to keep arguing.

-- 
--Guido van Rossum (python.org/~guido)