Recent Features
| |||||||||||||
A proposal for "rebooted" Python asynchronous I/O supportA proposal for "rebooted" Python asynchronous I/O supportPosted Jan 4, 2013 11:23 UTC (Fri) by smurf (subscriber, #17840)In reply to: A proposal for "rebooted" Python asynchronous I/O support by intgr Parent article: A proposal for "rebooted" Python asynchronous I/O support
Given that a model like gevent's is (a) a whole damn lot more natural to code to than all that "yield from" stuff, and (b) explicitly out of scope, I'd have to agree to the "rigid and obsolete" comment.
Debugging a maze of "yield from"s and/or explicitly registered callbacks is a *major* PITA. Been there, done that, given up, and re-implemented a couple of ten thousand lines with gevent instead of Twisted.
Fortunately, implementing a Twisted reactor on top of gevent has already been done, so the migration can be done in steps and is rather painless.
I am fairly sure that the same thing will be done for this PEP, once it's moderately final.
(Log in to post comments)
A proposal for "rebooted" Python asynchronous I/O support Posted Jan 6, 2013 2:35 UTC (Sun) by tack (subscriber, #12542) [Link]
In which framework were you tasked with debugging a maze of yield froms?
This is very different from the callback world of Twisted. The code reads fairly linearly like it would with gevent, except that your exit/entry points are explicit rather than implicit.
Having coded with both approaches (that is, explicit yields vs. greenlet-style implicitness) I prefer to be explicit. I rather like the visual cue that signals where my function will suspend and resume and I find this improves debuggability rather than hinders it. IMO, yielding gives you a nice bit of async magic while not violating the principle of least astonishment.
|
|||||||||||||