Python

Last week I was speaking at an Open Source panel at Better Software 2014, and one of the topics that we touched was code responsibility. This is an important topic for anyone who is maintaining an open source project, especially when it comes to the process of reviewing and accepting code contributions. At some point during the debate, I argued that when a maintainer merges a pull request, he (or she) implicitly agrees on being responsible for that code. That seemed to strike some surprise into most attendees. Yes, in theory any contributor is just a ping away so in case trouble arises one can always reach him, or her. Unfortunately this is not always the case. While some contributors will fully embrace your project and keep helping after their initial contribution, truth is that a good number of them will just move on, never to be seen again. There’s nothing wrong with that. Not everyone has spare time to devote to your project, which is perfectly fine. It is natural for most people to contribute what they need to a project and then go on their way. Actually, one could argue that most projects grow and prosper precisely thanks to this kind of contributions. However this attitude can become an incumbent when big chunks of code get merged, usually as new (big) features. Good practices advice against merging huge pull requests. In fact they are rare and when they do come, it is a good idea to ask for them to be split into smaller ones. But no matter the format, a huge contribution is likely to hit a project one day or another. It might even come from more than one person: a disconnected and distributed team of contributors who have been patiently tinkering on a side branch or a fork for example. When this happens, and provided that the contribution is worth merging, the maintainer should then ask him/herself the obvious question: am I willing to deal with the consequences of this merge? ...

The operations log or OpLog is a new Eve feature that I’m currently developing on the oplog experimental branch. It’s supposed to help in addressing a subtle issue that we’ve been dealing with, but I believe it can also emerge as a very useful all-around tool. I am posting about it in the hope of gathering some feedback from Eve contributors and users, so that I can better pinpoint design and implementation before I merge it to the main development branch. What is the OpLog? The OpLog is a special resource that keeps a record of operations that modify the data stored by the API. Every POST, PATCH, PUT and DELETE operation can eventually be recorded by the oplog. At its core the oplog is simply a server log, something that’s always been on the Eve roadmap. What makes it a little bit different is its ability to be exposed as a read-only API endpoint. This would in turn allow clients to query it as they would with any other standard endpoint. ...

OrderedDict is a super handy data structure. An OrderedDict is a dict that remembers the order that keys were first inserted. If a new entry overwrites an existing entry, the original insertion position is left unchanged. Deleting an entry and reinserting it will move it to the end. Problem is, this stuff is only available in the standard library since Python 2.7 while my project also needs to support Python 2.6. Fortunately there’s a back-port available and it is only a pip install away: # make OrderedDict available on Python 2.6-2.4 $ pip install ordereddict ordereddict is based on the awesome recipe by Raymond Hettinger, works with Python 2.4-2.6 and, most importantly, is a drop-in replacement for OrderedDict. However if you want your code to run seamlessly on all Pythons there’s still some work to be done. First of all you want to make sure that the appropriate OrderedDict is imported, either the standard library version (for Python 2.7 and above) or the back-port release. ...

Eve 0.4 adds cool features like Document Versioning and Coherence Mode. Cerberus 0.7 allows regex validation amongst other niceties. Make sure to check the official v0.4 announcement for all the details.

Python’s simple, easy-to-learn syntax can mislead Python developers – especially those who are newer to the language – into missing some of its subtleties and underestimating the power of the language. With that in mind, this article presents a “top 10” list of somewhat subtle, harder-to-catch mistakes that can bite even the most advanced Python developer in the rear. via 10 Most Common Python Mistakes.

Today we released Eve v0.3. It includes customizable Files Storage support (on GridFS by default), a lot of fixes, several breaking changes and a lot of love. Head over to relevant blog post and/or to changelog to know more about it.

Yesterday I gave a talk at FOSDEM 2014 in Brussels. The conference itself was amazing, with over 5000 attendees literally swarming and taking over the ULB Campus. I was stoked at how smoothly everything was going on despite the incredible number of simultaneous sessions and the number of attendees continuously flowing between buildings and conference rooms. Everybody involved, volunteers and attendees, has been very welcoming, charming and helpful. In short, I had a blast. ...

As a developer, I sometimes forget the power I yield. It’s easy to forget that, when something doesn’t work the way I’d like, I have the power to change it. via Python and Flask Are Ridiculously Powerful.

We shouldn’t really trust this kind of statistics, I know, but when my favorite language comes out as a clear winner, I can’t resist and take them for good. Python is the “language of the year” according to the PYPL index : it had the biggest increase in popularity share in 2013. PHP had the biggest decline. Meanwhile, Java continues to have the highest popularity share among the programming languages. ...

A very interesting read if you’re into Python. Eve has been Python 3 compatible for a while and honestl, I would be surprised to find that somebody is running it in production under Python 3. Why aren’t people using Python 3? First, I think it’s because of a lack of urgency. Many years ago, before I knew how to program, the decision to have Python 3 releases live in parallel to Python 2 releases was made. In retrospect this was a mistake, it resulted in a complete lack of urgency for the community to move, and the lack of urgency has given way to lethargy. ...