Dave Beazley's mondo computer blog. [ homepage | archive ]

Tuesday, March 19, 2013


From the future, import recipes

As many of you know, Brian Jones and I have been hard at work on the Python Cookbook, 3rd edition. If you haven't been following us, you might not know that the book is actually finished and in final production. In fact, O'Reilly brought some bound galley copies that we signed and gave away at PyCon.

Galley Copy of the Cookbook

Book signing at PyCon

Readers familiar with past editions of the Cookbook might be inclined to think that the 3rd edition is simply an updated version of that material. However, the upcoming edition is a completely new book, written from the ground up to target Python 3.3. Rather than focusing on past techniques and working within the restrictions of backwards compatibility, this edition aims to solve various problems in the most modern manner possible. Thus, if you're thinking about moving to Python 3 or simply learning more about how it's different, this is the book you'll want. We think you'll like it.

Although the official release date for the book is in May, you can get the book in progress as an e-book in O'Reilly's Early Release program. Also, if you keep a watchful eye, O'Reilly has been offering a 50% discount on the Cookbook in various promotions. For example, today (March 19), the cookbook is discounted in this promotion. An added benefit of the early release edition is that you get to submit errata for inclusion in the final book.

Last, but not least, if you're waiting for a print edition, look for it in the bookstore in late May. You can follow me on Twitter for the latest updates.

Wednesday, January 30, 2013


Build a Robot Army!

So, I was recently at an event where some students from Chicago's Northside College Prep High School showed up to demo some of their robots and to talk about their upcoming participation in the upcoming FIRST Robotics Challenge. For example, here's one of their past robots:

As a kid, I did more than my fair share of things related to computer programming, but I definitely never built a robot. Now that I'm an adult though (sic), I can definitely see the advantages that a robot might offer. For instance, programming it to chase my 3 and 4 year boys around, keeping a menacing eye on them when in "time out" (think Cylons), and cleaning up after their messes. However, where would I even start with a diabolical project like that? I don't know anything about robots.

As I've learned, sending a team to a robotics competition is no cheap affair. This is especially so if you're at a public school and you want to equip your basic entry-level robot with all sorts of cool accessories such as laser beams, plasma torches, x-ray vision and stuff. And don't even talk about travel. No, seriously, these students are probably all going to be huddled in a van using the robot's plasma torch just to stay warm. On a serious note, this is actually the very first year that Northside has participated in the FIRST Robotics Challenge. As a rookie team, time and resources aren't always easy to come by.

Sensing an opportunity, I've decided to help solve both problems by sponsoring a Build a Robot Army event on February 9, 2013 at my office in Chicago. The Northside students are going to stop by with some robot kits and teach everyone the basics of building a robot. It's limited to only 8 people. As such, it will be hands-on and in-depth. All of the proceeds will go to help the Northside team. In short, it will be an awesomely fun way to spend a Saturday afternoon.

More information is available at http://robotarmy.eventbrite.com. I hope to see you there! -Dave

Wednesday, July 04, 2012


If you remove the GIL, will it leave a GIL-shaped hole?

So, I recently assembled a Shapeoko CNC machine and was deciding what do with it for a first test run. Naturally, writing a Python 3 script to literally remove the "GIL" from a board came to mind.

Here is the video of it being milled:

Yep, removing GILs with Python 3 and power tools---all in a days work. That's all for now.

Tuesday, March 13, 2012


PyCon 2012 Followup

Well, PyCon 2012 has come and gone. It was fantastic to see everyone and to learn new things. For me, I think the big takeaway from the conference was all of the activity surrounding scientific computing and data analysis. The ipython notebook project is really quite amazing--I will need to spend more time checking that out. As a former stats geek, I'm also quite interested in checking out pandas. Last, but not least, I really enjoyed chairing the session on GIS tools. I have taken a recent interest in GIS and mapping, but quickly realized that I was way out of my element with it. The talks were a nice way to connect with some of the tools and techniques involved.

The 5.72 missing slides from my keynote

In my keynote talk on PyPy, I somehow managed to cover 123 presentation slides with 2 minutes to spare. Vern Ceder then noted that I now owe everyone an extra 5.72 slides. So, without further delay, here are the 5.72 extra things I wish I could have included in my PyPy Keynote:

  1. Even the Mandelbrot set code that I presented doesn't do PyPy's performance justice. I have been experimenting with some other libraries including a graphics library and a program for molecular dynamics. On these programs, I've seen speedups of almost 50x going from CPython to PyPy. It's pretty amazing.
  2. Don't panic about the amount of source code! Even though there are about 1.25 million lines of Python code in the full PyPy distribution, a huge chunk of that is the Python standard library (maybe 500-600K lines). There are also a lot of unit tests, supporting tools, and other things. Thus, in terms of actual code, the size of PyPy itself is not that big. The main point is that if you just dive into PyPy without knowing much about it though, you will see an awful lot of Python code sitting around.
  3. Don't let the documentation and papers intimidate you. I have found that over time, with repeated readings and messing around, the material all starts to come together in a more coherent way. It's just that when you first start, it can all be a bit overwhelming.
  4. RPython gives you much more than just translation to C. You also get important things such as garbage collection and useful containers. Actually, one of the main benefits of RPython is that you don't have to worry about such low-level details as memory allocation, pointers, and other matters commonly associated with C programming. These extra features are why even translating a simple "Hello World" program includes quite a bit of supporting C code.
  5. It's also important to strongly emphasize that RPython is simply the implementation language for PyPy. That is, PyPy is a Python interpreter that just so happens to be written in RPython, much like CPython is a Python interpreter written in C. It's important to note that RPython can be used all on its own to implement new programs and interpreters for other unrelated languages.
  6. (.72) I have been working on a simple GIL removal patch, but...

If you've been using my past GIL work to troll, please stop it already

In Guido's keynote talk, he talked about feeding trolls and at one point mentioned the GIL. Having done a lot of past work trying to understand the GIL, I'd like to say a few words about that. First of all, if you think that my primary interest in the GIL is to show how Python threads (or Python itself) suck, then you would be wrong. You will not find either claim in any of that work nor will you find me online engaging in discussion about such things.

The truth of the matter is that threads are my preferred means of concurrent programming in Python. Not only that, they work extremely well for all sorts of problems involving I/O. However, if you're going to program with threads, it's important to be aware of situations where they do not work as well. In the case of Python, this mostly pertains to programs that try to subdivide computation across threads. There are also potential issues with code that overlaps heavy computation with background I/O handling. Thus, my main interest in the GIL has been to explore some of these corner cases in some detail with an eye towards improving the GIL implementation--something that I consider to be a worthy goal. More generally, I think the GIL is interesting to study as a systems programming puzzle on its own.

In any case, the performance of threads is highly specific to the application at hand. You can't just take some benchmark from one of my GIL talks and extrapolate that out to a general statement about all Python thread programming. Personally, I find that Python threads have worked pretty well for most of the problems where I've used them. Of course your mileage might vary.

Angry Birds

Last, but not least, I never should have gone to Jason Huggins's talk about the robot that plays Angry Birds. I have now become that robot when I should be working on my concurrency workshop. Argh!


Prior Posts by Topic

08/01/2009 - 09/01/2009   09/01/2009 - 10/01/2009   10/01/2009 - 11/01/2009   11/01/2009 - 12/01/2009   12/01/2009 - 01/01/2010   01/01/2010 - 02/01/2010   02/01/2010 - 03/01/2010   04/01/2010 - 05/01/2010   05/01/2010 - 06/01/2010   07/01/2010 - 08/01/2010   08/01/2010 - 09/01/2010   09/01/2010 - 10/01/2010   12/01/2010 - 01/01/2011   01/01/2011 - 02/01/2011   02/01/2011 - 03/01/2011   03/01/2011 - 04/01/2011   04/01/2011 - 05/01/2011   05/01/2011 - 06/01/2011   08/01/2011 - 09/01/2011   09/01/2011 - 10/01/2011   12/01/2011 - 01/01/2012   01/01/2012 - 02/01/2012   02/01/2012 - 03/01/2012   03/01/2012 - 04/01/2012   07/01/2012 - 08/01/2012   01/01/2013 - 02/01/2013   03/01/2013 - 04/01/2013  

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]