pyuv 1.3.0 released!

Looks like I’m on a release spree! Today I’m releasing pyuv (libuv bindings for Python) version1.3.0.

This release focused on 2 main things:

  • Update to latest libuv release: 1.9.1
  • Add Python 3.5 support

There are other (small) bugfixes too, check the full changelog for details. One of the things I’m most happy about is that thanks to AppVeyor I’m able to provide Wheels for Python 2.7, 3.3, 3.4 and 3.5 on Windows (32 and 64 bits) so you don’t have to compile pyuv, which is sadly not straightforward on Windows; checkout the PyPI page.

Enjoy!

pyuv 1.2.0 released

Quick heads up, I just released pyuv 1.2.0. pyuv is a Python wrapper for libuv. This time around, pyuv implements all the funcionality covering up to libuv 1.7.3.

This release was focused in 2 things: adjusting to new APIs / changes in libuv, and improving the testing, specifically on Windows.

As of this writing, pyuv is automatically tested on Linux systems thanks to Travis CI and on Windows thanks to AppVeyor. Thanks to AppVeyor, I’m now able to provide Python Wheels for pyuv, which is great because, frankly, compiling it on Windows is kind of a pain.

See the ChangeLog for a detailed outline of the changes, check the documentation, and fetch the code on GitHub. Packages have also been uploaded to PyPI.

pyuv 1.0.0 released!

In case you missed the news, libuv 1.0.0 was released not long ago, so now it’s time for pyuv to hit 1.0.0.

Hitting 1.0.0 means the API will remain backwards compatible throughout the 1.x branch. But this came at a cost: pyuv 1.0.0 introduced several backwards incompatible API changes, some coming from changes in libuv itself, and some others to (hopefully) improve pyuv itself.

Here is the full changelog.

As usual, you can download pyuv from PyPI, and check the documentation here.

“So, what now?” I hear you say. Since pyuv is currently feature-complete with regards to libuv, adding CFFI bindings to pyuv will probably be the next thing I’ll tackle. You can follow the discussion here. A user already started, and I look forward to joining forces and integrating the work 🙂

New pyuv stable and pre releases

Took a while to get these together, mainly because I’m spending quite some time on libuv itself lately. In case you didn’t know libuv 1.0.0 is around the corner, yesterday libuv 1.0.0-rc2 was released, check it out!

Back to pyuv, I’m pleased to announce pyuv version 0.10.12, which a maintenance release for the v0.10 series. In addition, I’m releasing pyuv 1.0.0.dev1, the first development release in the v1.x series of pyuv (which bundles libuv 1.0.0-rc2).

Enjoy!

: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

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:

And here is the equivalent in pyuv 0.11:

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:

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

 

pyuv 0.10.0 relased!

Today I’m happy to announce that pyuv 0.10.0 has been released! Following libuv’s versioning, this is a stable release, that is, no API changes will occur during the 0.10.x branch cycle.

It has been a while since the last stable release, there have been many changes, even though not all of them are directly visible in the public API. Here is a short list of the most relevant changes for version 0.10.0 since the 0.8 series:

  • Added a true signal watcher
  • Added ability to handle uncaught exceptions (Loop.excepthook)
  • Added TCP.open and UDP.open methods
  • Added support for compilation with Visual Studio in Windows
  • Added thread module with several thread synchronization primitives
  • Added mode parameter to Loop.run (default, once or nowait)
  • Added fileno and get_timeout methods to Loop
  • Added ability to cancel threadpool, getaddrinfo and fs requests
  • Added ability to stop the event loop (Loop.stop)
  • Moved getaddrinfo to util module
  • Removed builtin c-ares resolver
  • Removed get/set process title functions
  • Fixed numerous refcounting issues
  • Multiple fixes for Windows
  • Multiple memory related internal optimizations

There are many more changes, all listed in the changelog file.

I’m glad to say that pyuv is now in better shape than it ever has been. Not only because I have learned many things along the way, but also because I got really good pull requests and help which enhanced pyuv in many different ways. I’m not a Windows guy and got invaluable help from people which helped make pyuv work properly on Windows. Releases 0.9.5-6 contain more commits from others than from myself, and I love that!

Last, I’d like to thank the libuv core team, more specifically Ben and Bert. They do a great job both coding libuv itself and helping others get involved in the project. This is one of the projects I’m really happy I contribute to. Oh, I also scored 4th in the libuv contributions (in lines of code) for Node 0.10.0!

You can get the source code at the usual place, and check the updated documentation here.

Rose: a PEP-3156 compatible event loop based on pyuv

For those who don’t know, PEP 3156 is a proposal for asynchronous I/O in Python, starting with Python 3.3. Until now each framework (Twisted, Tornado, …) has defined it’s own interface for defining protocols and transports. This makes very difficult if not impossible to reuse a protocol implementation across frameworks. PEP 3156 tries to fix that, among other things.

The reference implementation is called Tulip and can be found here. It’s a fast moving target, but it already contains working event loops for Windows and Unix systems. It uses pollers available in the select module for the Unix side, and a C module wrapping Windows IOCP functionality for Windows.

I was really excited to see this come through, so I started playing with it by implementing a pyuv based event loop. I called that it rose. It was a lot easier to implement than expected and it currently passes the entire test suite 🙂

Code can be found on GitHub.

Here is a quick example, the usual echo server, using rose and tulip:

Come and join the discussion in the python-ideas mailing list!

:wq