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.
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
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).
Tonight I had the opportunity of speaking at the DomCode meetup in Utrecht. I gave a presentation titled “Python, do you even async?” where I gave an overview on the different ways to do asynchronous I/O in Python, focusing on asyncio for the most part. Here are the slides for those interested:
I had a blast, the venue was great and I got to talk to some great people, I hope to be back!
Thanks a lot to the organizers and App Annie for hosting us and providing the pizza and drinks!
Long time no blog :-S Just a quick one to let you know pyuv 0.11.5 has been released. The 0.12 release is close by and I already started preparing, this release introduces some backwards incompatible changes, but I assuer you, it’s for the better
The API has been overhauled in order to provide 2 different ways of doing things:
A synchronous API, which will spawn a green thread and wait for it for every request sent this way
An asynchronous API, which just prepares the requests, allowing the user to throttle them with map or imap
Another important improvement is that when sending requests with map/imap, if one of them fails with an error, the exception object is returned, instead of raising it and stopping the process in the middle.
Here is an example script showing both APIs:
Last but not least, I’d like to thank Juan Riaza for his help in designing the API and adapting the tests.
It has been an intense weekend. I’ve been in Madrid for PyConES, and all I have to say is that it was amazing! Lots of great talks, old friends and new ones, I had a blast!
I gave a presentation on Tulip/asyncio in Spanish, but since code kind of speaks for itself, you may find some value in my slides here:
This is a hot topic these days, and proof of that is the fact that mine wasn’t the only Tulip/asyncio talk at PyConES. I had the pleasure to work with Iñaki Galarza, who also gave a presentation about Tulip so that our talks would complement each other’s. You can find his slides here:
I really hope I can make it next year, and you should too!
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!
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 pyuvabout 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
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!