Eventlet A better way to write network applications

Eventlet 0.9.6 has gone gold, and you can pick it up from your favorite PyPI.

This release is unique, because I feel that it’s the most community-driven one: the majority of code came from the sprinters in Hanover C.  And, man, is this a good batch of contributions, and there are more in the pipeline.  If you haven’t heard of Pycon and its sprints, they’re where a bunch of nerds get together and sit in a windowless room with occasional beer injections, coding and sharing ideas and being productive without being too serious.

We spent our time doing everything from improving PEP-8 compliance to refactoring the way timers are handled in the hubs.  Mad props go out to the following sprinters who I had the pleasure of meeting in person (in no particular order, and let me know if I totally forgot you): Chris AtLee, Eugene Oden, Ada Majorek, Chuck Thier, Mike Barton, Andrew Svetlov, Tavis Rudd, Brantley Harris, and Donovan Preston.

Here’s the changelog for 0.9.6:

• new EVENTLET_HUB environment variable allows you to select a hub without code
• improved GreenSocket and GreenPipe compatibility with stdlib
• bugfixes on GreenSocket and GreenPipe objects
• code coverage increased across the board
• Queue resizing
• internal DeprecationWarnings largely eliminated
• tpool is now reentrant (i.e., can call tpool.execute(tpool.execute(foo)))
• more reliable access to unpatched modules reduces some race conditions when monkeypatching
• completely threading-compatible corolocal implementation, plus tests and enthusiastic production adoption
• tests stomp on each others’ toes less
• performance improvements in timers, hubs, greenpool
• Greenlet-aware profile module courtesy of CCP
• support for select26 module’s epoll
• better PEP-8 compliance and import cleanup
• new eventlet.serve convenience function for easy TCP servers

Remember that this is intended to a stabilization release, so mostly stabilization-related stuff made it into this.  Some of these stemmed from people testing out existing apps with Eventlet and finding a bug, writing a test, and committing fixes.   That’s exactly the way it’s supposed to be!

Interesting images after the jump.

You may be aware that Eventlet’s stability is guarded by our use of Hudson to continuously run the tests whenever we commit to the trunk.  One of the cool effects of using Hudson is that we get a bunch of nice graphs to look at.  Here’s the graph of test quantity (here’s the live version):

We started sprinting at around build 163.  There’s kind of a little story in that graph: I checked in a change around 164 that broke the tests pretty badly, then I didn’t fix it for a while and instead integrated a bunch of changesets from sprinters, and then I finally fixed the main cause of all those failures with the help of hg bisect, and found ourselves on a higher plateau thanks to all the tests that had been added by those changesets.  These remained largely stable and a few more tests just rolled in.  Cool!

Here’s a similar graph for code coverage:

Ignore the low bit on the left there; that was just me figuring out how to get the dang coverage reports to show up in the first place.  Again, we started sprinting around build 163.  This graph ignores failed builds, so it doesn’t have the gulleys the previous one does.  The important thing is that we got coverage up from 70% to 80%, which is huge!  Test coverage is definitely asymptotic in nature in that the last few percentage points take hugely more effort than the first few — heck. you get 40% just from doing nothing other than importing it!  I think that we may be very near to the maximum possible code coverage here; if you look at the full coverage report for a recent build, you’ll see that most of the missing lines are either in a separate process (which apparently is addressed with the new version of coverage), or are for a platform that the test wasn’t running on (which maybe we can address via some sort of coverage aggregation of all the Hudson build results).  Actually, now that I look at things, I bet I can get a few more percentage points just out of dinking around with coverage.

The point being!  These coverage gains during the sprints are real, and hard-won.  Thanks so much for your contribution, contributors!