[Python-ideas] re-implementing Twisted for fun and profit

[Shane Green]

Hm, just jumping in out of turn (async ;-)  here, but I prototyped pretty clean versions of asyncore.dispatcher and asynchat.async_chat type classes built on top of a promise-based asynchronous I/O socket-monitor.  Code ended up looking something like this following: 

# Server accepting incoming connections and spawning new HTTP/S channels…
this.socket.accept().then(this.handle_connection)

# With a handle_connection() kind of like…
def handle_connection(conn): 
	# Create new channel and add to socket map, then…
	if (this.running()): 
		this.accept().then(this.handle_connection)

# And HTTP/S channels with code like this…
this.read_until("\r\n\r\n").then(this.handle_request)

# And handle-request code that did stuff like…
if (this.chunked):
	get_content = this.read_until("\r\n").then(self.parse_chunk_size).then(this.read_bytes)
else:.
	get_content = this.read_bytes(this.content_length)
return get_content.then(handle_content) 


I'll look around for the code, because it's been well over a year and wasn't complete event then, but that should convey some of how it was shaping up. 




Shane Green 
www.umbrellacode.com
805-452-9666 | shane at umbrellacode.com

On Oct 14, 2012, at 7:07 PM, Glyph <glyph at twistedmatrix.com> wrote:

> On Oct 13, 2012, at 9:49 PM, Guido van Rossum <guido at python.org> wrote:
> 
>> It seems that peraps the 'data_received' interface is the most important one to standardize (for the event loop); I can imagine many variations on the handle_read() implementation, and there would be different ones for IOCP, SSL[1], and probably others. The stdlib should have good ones for the common platforms but it should be designed to allow people who know better to hook up their own implementation.
> 
> 
> Hopefully I'll have time to reply to some of the other stuff in this message, but:
> 
> Yes, absolutely.  This is the most important core issue, for me.  There's a little more to it than "data_received" (for example: listening for incoming connections, establishing outgoing connections, and scheduling timed calls) but this was the original motivation for the async PEP: to specify this interface.
> 
> Again, I'll have to kick the appropriate people to try to get that started again.  (Already started, at <https://twitter.com/glyph/status/256983396826378240>.)  It's on github so anyone can contribute, so if other participants in this thread - especially those of you with connections to the Tornado community - would like to try fleshing some of it out, please go ahead.  Even if you just have a question, or an area you think the PEP should address, file an issue (or comment on one already filed).
> 
>> (Thanks for writing this; this is the kind of insight I am hoping to get from you and others.)
> 
> Thanks for the repeated prompts for Twisted representatives to participate.
> 
> I was somewhat reluctant to engage with this thread at first, because it looked like a lot of meandering discussion of how to implement stuff that Twisted already deals with quite effectively and I wasn't sure what the point of it all was - why not just go look at Twisted's implementation?  But, after writing that message, I'm glad I did, since I realize that many of these insights are not recorded anywhere and in many cases there's no reasonable way to back this information out of Twisted's implementation.
> 
> In my (ha ha) copious spare time, I'll try to do some blogging about these topics.
> 
> -glyph
> 
> [1]: With one minor nitpick: IOCP and SSL should not be mutually exclusive.  This was a problem for Twisted for a while, given the absolutely stupid way that OpenSSL thinks "sockets" work; but, we now have <http://twistedmatrix.com/trac/browser/trunk/twisted/protocols/tls.py> which could probably be adapted to be framework-neutral if this transport/event-loop level were standardized.
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121014/f56d1440/attachment.html>