“The future of async i/o in Python”, slides

Today I had the pleasure to talk at the Amsterdam Python Meetup Group about Tulip, PEP-3156 and async i/o in Python. Here are the slides:

[slideshare id=26802486&doc=thefutureofasyncinpython-131002171955-phpapp01]

Big thank you to the guys at Byte for hosting tonight’s meetup and providing us with nice drinks and pizza 🙂

Already looking forward to the next one!

:wq

Fibers 0.2.0 released, now with PyPy support!

Hi there!

I just released python-fibers 0.2.0, which includes PyPy support! For those of you who may not know, here it what fibers are all about:

Fibers are lightweight primitives for cooperative multitasking in Python. They provide means for running pieces of code that can be paused and resumed. Unlike threads, which are preemptively scheduled, fibers are scheduled cooperatively, that is, only one fiber will be running at a given point in time, and no other fiber will run until the user explicitly decides so.

The funny thing here is that the implementation of fibers uses code (stacklet, more precisely) borrowed from PyPy, but the first version of fibers only supported CPython. On this version, a PyPy compatible version is provided, using the _continuation module. For reference, the greenlet and stackless implementations in PyPy are done using this module. It has been tested with PyPy 2.1, but let me know if you run into any issues!

You can grab it at your nearest cheese shop, get it while it’s hot!

:wq

On the libuv core team!

My week couldn’t have ended better. Today while I was working Bert pinged me on IRC and told me I was getting commit access to the libuv project (he even announced it!). I hadn’t asked for this nor I needed it, but I’m so glad it happened.

First time I heard about libuv it wasn’t even called like that, it was called liboio (here is an old clone) and it was presented by Ryan Dahl as the solution for NodeJS on Windows. This happened between Node 0.4 and 0.6, since Node 0.6.0 was the first version to ship with libuv. It wasn’t until a bit later when I really started playing with it.

I started writing pyuv about two years ago with the purpose of using it as the backend for some project (that ended up being evergreen, but it took a while to get there) but more importantly, I wanted to enhance my C coding skills and learn more about the CPython internals.

Fast forward 2 years. I’m no C guru, but I feel much more comfortable writing C and I think I did improve a lot. Most of this came from contributing to libuv. Ben and Bert are great maintainers, not only because they write top quality C code (I’ve learned so much just by reading) but because they know how to build a community around the project. It’s difficult to put it in words, but after interacting with many Open Source projects, libuv has been one of those where I just want to stick around, use it, improve it and help others use it.

This came to me as a surprise, and I hope I can continue to help libuv even better now 🙂

achievement

:wq

Evergreen 0.2.0 released!

I’m very happy to announce I just released evergreen 0.2.0! From the API standpoint, not many things changed, but a number of important internal changes happened, including a change in how callbacks are scheduled in the event loop, which fixed a nasty issue in Windows.

For those who may not know:

Evergreen is a cooperative multitasking and i/o library for Python. It provides equivalent primitives to those for thread programming, but uses a cooperative model instead.

Operations are driven by an event loop which will run the given tasks and i/o operations in a non-blocking manner while presenting the user a synchronous, blocking API.

Here is the full changelog:

 – Revert “Don’t allow futures to be used more than once”
 – Break potential cycle because we are storing the traceback
 – Fixed passing traceback when propagating exception to MAIN parent
 – Process all callbacks using an Idle handle
 – Replaced use of Future in io module for Result
 – Don’t wait for send operation to complete in UDPEndpoint
 – Always run tests from the right directory
 – Fix UDP test case on Windows
 – Added flush() method to UDPEndpoint and Stream objects
 – Cache sockname and peername properties
The code can be downloaded from GitHub, as usual. Hope you like it!
:wq

uvwsgi: a Python WSGI server

I’ve been playing with Flask and WSGI in general for a few nights… at some point I started playing with pyuv and http-parser and before I realized I had a really basic WSGI server to play with: uvwsgi.

It’s not meant for production usage (yet) but should be really simple to understand, it’s less than 400 lines of code!

Here is a list of things I’d like to implement, in no particular order:

  • Multi-process support using socket sharing
  • Multi-process support using a single acceptor and a pool of worked which get connections dispatched round-robin
  • Update http-parser to the latest and greatest version
  • Automatically restart server if modules changed
  • Tests

You can install it from the cheese shop or get the code on GitHub.

Patches are welcome, of course 🙂

:wq

 

fibers: lightweight cooperative microthreads for Python

Hi all!

Today I’m really happy to share the first version of fibers, a project I’ve working on for a while.

Fibers are lightweight primitives for cooperative multitasking in Python. They provide means for running pieces of code that can be paused and resumed. Unlike threads, which are preemptively scheduled, fibers are scheduled cooperatively, that is, only one fiber will be running at a given point in time, and no other fiber will run until the user explicitly decides so.

When a fiber is created it will not run automatically. A fiber must be ‘switched’ into for it to run. Fibers can switch control to other fibers by way of the switch or throw functions, which switch control or raise and exception in the target fiber respectively.

 

This project is heavily inspired by greenlet, as you may have noticed. I’ve been using greenlet for a long while, but for a recent project I’ve worked on, I wanted to offer an interface similar to the Thread class from the threading module. Unfortunately the API in greenlet didn’t make it easy, so I took it as an excuse to try to build the library I wanted to use, which hopefully also helps others.

The obvious step would have been to fork greenlet itself and change the API to my needs, but I randomly ran into stacklet, a tiny library hidden in the PyPy source code, which is used as the base for the greenlet implementation in PyPy.

So, I stood on shoulders of giants and built fibers using stacklet. It solves my problems, hopefully it can help you too! In case you are interested in a more verbose version of the project rationale, I added a specific section in the documentation.

The source code is available on GitHub, with MIT license, enjoy!

import fibers

def runner(*args, **kw):
    print "hello, I'm running inside a fiber! - %r" % fibers.current()

f = fibers.Fiber(target=runner)
f.switch()

:wq

pyuv 0.10.5 (stable) and 0.11.0 (unstable) released!

I’m happy to announce two new pyuv releases today: pyuv 0.10.5 (stable) and 0.11.0 (unstable). Why two releases? For those who may not know, pyuv follows the NodeJS release cycle, that is, odd numbered releases are the so called “unstable” releases, while the even numbered releases are “stable”.

The 0.10.5 release brings  few bugfixes and embeds the latest version of libuv, so you also benefit from the bugfixes in libuv.

pyuv 0.11.0 includes some heavy refactoring of the filesystem operations, which unfortunately are not backwards compatible, but I hope it’s for the best:

In pyuv 0.10x this is the way to stat a file asynchronously:

def cb(loop, path, result, error):
    if error is None:
        print result
    # ...

pyuv.fs.stat(loop, 'test.py', callback=cb)

And here is the equivalent in pyuv 0.11:

def cb(req):
    if req.error is None:
        print result
    # ...

req = pyuv.fs.stat(loop, 'test.py', callback=cb)

All filesystem operations now get a single argument in the callback: the FSRequest object which was returned to the caller when the function was initially called. The loop, path, result and error are now attributes of the request object. Moreover, the request object now has an instance dictionary, so you can attach any attribute to it and use it later:

def cb(req):
    assert req.foo == 'foo'
    if req.error is None:
        print result
    # ...

req = pyuv.fs.stat(loop, 'test.py', callback=cb)
req.foo = 'foo'

There have been other big internal changes due to changes in libuv itself, but those are not visible in pyuv since it provides a class-level abstraction.

The next stable release will be pyuv 0.12.0, right when Node 0.12 is launched. Until then 0.10 will remain as the stable branch, and the one installable through PyPI, those of you interested in the latest and the greatest, go fetch master on GitHub 🙂

:wq

 

Serving a WSGI app, WebSockets and static files with Twisted

Long time no post! Lets solve that now shall we?

A few days ago I started playing a bit with Flask, since I’m considering it as the framework to build some API server. I have no web development experience, and Flask looks like a great project so I went with that.

I started with a tiny little hello world, and then I wanted to add some websockets and some CSS. Oh the trouble. When I started looking for how to combine a Flask app with WebSockets I found references to gevent-socketio for the most part, but I somewhat wanted to use Twisted this time, so I kept looking. Soon enough I found AutoBahn, a great WebSocket implementation for Twisted, which can be combined with a WSGI app, brilliant! After seeing how AutoBahn manages to add the websocket route to the WSGI app, adding support for static files was kind of trivial.

Here is the result of my experiments, a really simple web app which consists of a Flask WSGI app, a WebSocket server and some static files, all served by the same process running Twisted. You may not want to do this in a production environment, but hey, I’m just playing here 🙂

[gist]https://gist.github.com/saghul/5961882[/gist]

Since Gist does not currently allow folders, make sure you keep this layout after downloading the files:

├── app.py
├── settings.py
└── templates
    ├── assets
    │   └── style.css
    └── index.html

We’ll use the twistd command line tool to launch out application, since it can take care of logging, running as a daemon, etc. To run it in the foreground:

twistd -n -l - -y app.py

This will launch the application in non-daemon mode and log to standard output.

Hope this helps someone, all feedback is more than welcome 🙂

:wq

Evergreen 0.0.4 released!

It’s been a while since I haven’t posted around here! I made a few evergreen releases which are probably worth mentioning. They are pretty minor, no big changes have happened. The module which got most of the work is the io module, which I expect to improve more, as well as add cooperative UDP, TLS and file I/O support.

In addition, I created a couple of packages extending evergren’s functionality:

If you are using evergeen, let me know! Hopefully I can continue to make it better bit by bit.

:wq

 

Evergreen: cooperative multitasking and i/o for Python

I’ve been working on-and-off on this project for almost a year during my free time, and after meditating about it I thought: “fuck it, ship it”. Allow me to introduce Evergreen: cooperative multitasking and i/o for Python.

“So, another framework?” I hear you say. Yes, it’s another async framework. But it’s my async framework. I’ve used a number of frameworks for developing servers in Python such as Twisted, Tornado, Eventlet, Gevent and lately Tulip and all of them have great and not so great things, so I decided to blend the ideas I gathered from all of them, add some opinionated decisions, some Stackless flavour and Evergreen was the result.

standards

Evergreeen is a framework which allows developers to write synchronous looking code which is executed asynchronously in a cooperative manner. Evergreen presents an API which looks like the one you would use to write concurrent programs using threads or futures from the Python standard library. The facilities provided by Evergreen are however cooperative, that is, while a task is busy waiting for some i/o other tasks will have their chance to run.

“Show me the code!” I hear you say. Sure, it’s up here on GitHub, released under the MIT license. Since the usual example is a web crawler, here you have one.

Did I mention it supports Python 2 and 3?

“Is it production ready?” I hear you say. It’s still on a very early stage, but I believe the foundation is solid. However, the APIs provided by Evergreen may change a bit until I feel confortable with them. All feedback is welcome, so if you give it a try do let me know!

I’d like to thank all authors of similar libraries for releasing their work as Open Source which I could look into and learn from.

I hope Evergreen can help you solve some problems and you enjoy using it as much as I do developing it.

:wq