Monthly Archives: March 2009

The PyCon Summits

This year at PyCon there are two new events, a Dynamic Language Virtual Machine Summit, and a Python Language Summit. Each summit lasted one day, and occurred during the tutorial program of the main PyCon conference. I am really happy to see these events happen, to take advantage of people all being in one place.

Dynamic Language Summit

The organizers of this summit invited a broad variety of virtual machine implementors to meet and discuss their successes and challenges in implementing various dynamic languages.

Sun has hosted a similar summit for people implementing languages on the JVM, and Microsoft’s Lang.NET, which is their corresponding event for the CLR, is in a few weeks. There’s been a nice cross pollination of people between those summits. The PyCon event is the corresponding event for people working on non-JVM/CLR virtual machines. I would love to see all of these communities cross pollinating each other eventually.

The VM’s represented were CPython, PyPy, Jython, JRuby, Parrot, MLVM/Da Vinci Machine, IronPython, DLR, Factor, TraceMonkey, Cog, unladen_swallow, Rubinius, and MagLev. Since this was the first time this group of people met together, we spent the morning doing brief introductions of the various projects. From there the room exploded into a bunch of small unstructured discussions. There were many of these, and they are hard to summarize, so I am going to pass on trying to summarize this any further. I really would have liked to see representatives from PHP, Erlang, io, Newspeak, SquirrelFish, and V8.

Disclosure: I was involved in getting Sun to sponsor this summit (and PyCon)

Python Language Summit

The Python Summit was focused on bringing together developers of Python implementations and the Python standard library in order to discuss issues of importance to Python. Major scheduled topics included the roadmap for Python 2.x/3.x (including release scheduling), cross-implementation issues, and package distribution and installation.

During the 2.x/3.x section, there was some question about whether or not “batteries included” was still the right approach for the standard library or whether improvements to packaging mechanisms might lead to a different approach. Since packaging still has some major issues, there wasn’t a lot of progress on this front. There was also some discussion on the merits of using C++ in the Python compiler. Again not much of a conclusion here, but the majority of the thought in the room was to use a few C++ features as possible. There was also discussion of including some improvements to unittest.
The largest discussion during that section, was of course, the roadmap for 2.x versus 3.x, and how to encourage people to move from 2.x to 3.x. It looks like there is (good) reluctance to keep the 2.x series moving forward, so there may be a long (possibly infinitely long) gap between 2.7 and 2.8. At the same time, it seems clear that 3.1, which is currently in alpha, will be the first truly usable release in the 3.x line. The goal is to get 3.1 out pretty quickly and deprecate 3.0 – an odd and one time practice for the Python community. There was also a discussion of what could be done to help library and framework developers jump to 3.x. One concrete outcome was agreement to start work on a 3to2 tool which would allow developers to develop on 3.x and then backport to 2.x, thus helpoing developers to flipp their effort into (in my opinion) the correct release stream

The cross implementation session was uncontroversial and very friendly. One thing that I love about the Python community is the openness to alternate implementations of the language. Implementors of the alternate implementations were encouraged to just go and do what was needed to accommodate their needs. One item that came up was the utility of splitting the standard lib, the unit tests, and (perhaps) the docs, so that all implementations could reuse them. Everyone agreed that this was a good idea, so look for this to happen soon. Also, developers of the alternate implementations were given commit bits to CPython and told to make the necessary changes. One phrase that I heard during the discussion was “putting CPython on an equal footing with the other implementations”. Based on the decisions and actions during the session, I’d say this is way more than lip service.

The last planned session covered the issue of packaging. Tarek Ziade presented the results of his packaging survey. After that there were introductions of a few of the isolation tools, virtualenv, and zc.buildout. I’d never taken a serious look at zc.buildout, but Jacob Kaplan-Moss convinced me to take a serious look by showing a sample buildout file. Apparently the documentation for zc.buildout is sorely lacking, so if any readers are zc.buildout experts or fans, please leave a comment with pointers. From there, discussion went on to a very good list that Tarek assembled. You can read his final summary of the discussion as well as what should happen next.

unladen_swallow

One unscheduled item that got a lot of buzz was the unladen_swallow project. This is a branch of CPython (2.6 initially, but eventually forward ported to 3.x) initiated by people at Google, with the goal of improving CPython’s performance by 5X. A 5X speedup would be pretty amazing – the details of how they plan to accomplish this are in the project plan. Apparently it is already 30% faster than CPython, and this version is being used to run some of the Python code on YouTube. They have yet to embark on the task of integrating LLVM as JIT for Python. I am also happy to see that they are going to tackle removal of Python’s global interpreter lock (GIL). The team at Google is planning to merge their code back into the main CPython implementation, and have been discussing this in detail with the existing core Python developers. The unladen_swallow is focusing on Linux, but they told me that they would gladly accept community help for testing on Macintosh, Windows, and other platforms.

Ever since the Javascript engine arms race started earlier this year, I’ve been concerned about the lack of a similar situation in the various dynamic language communities. It appears that things in the Python world are starting to heat up.

On the whole, I found these two summits to be highly useful. I hope that the PyCon organizers will do them again.

Lifestreaming, round 2

1 Reply

Macintosh

MRR Software has released a beta of Syrinx 2.0 just in time for PyCon this week (or ApacheCon EU or EclipseCon, if you are at one of those events). My biggest complaint with Syrinx 1.0 was that it was using up a lot of memory and CPU. That’s totally fixed in Syrinx 2.0. I’ve left Syrinx running for over a day with very little discernable growth in memory. I used to have to restart it several times a day. Scrolling and searching are both much faster as well. Retweet and URL shortening have been added, which pretty much takes care of me featurewise, although I’d like a retweet button in the button bar of a tweet, and I’d prefer bit.ly as the URL shortening service. Minor complaints to be sure. The last UI issue for me is that Syrinx 2.0 now expands the current tweet from it’s slightly compressed list element version. This is a problem for tweets that contain links (the best kind), because you have to click once to zoom the tweet, and then click again to open the link. I know that MRR is working on this one.

iPhone

Several week ago I also switch my iPhone client from Twitterific to Tweetie. I love everything about Tweetie except for 2 things:

1. Tweetie goes to the network all the time. This wouldn’t be a problem if iPhone latency was just a bit better.

2. I don’t like the way the Tweetie segments replies and direct messages. I like having tabs to see just those things, but I don’t like it that they no longer appear in the main view. Syrinx is doing it the way that I prefer.

My favorite features about Tweetie are:

1. Network lag aside, Tweetie is speedy.

2. The swipe actions, particularly favorites – I now favorite a lot more. This saves me from losing tweets with interesting links when I am in a hurry. I fave them on the phone and then read the faves from the desktop.

3. Instapaper support. I’m glad this is here, but I use it less than I thought I would, because of favorites

4. The landscape mode keyboard – This is taking some getting used to, but it’s good practice for iPhone 3.0

5. Ability to say how many tweets to load – good for making sure you don’t miss anything

6. Retweeting – too bad it doesn’t fit in the swipe bars.

There’s still no direct message rolodex, something that I am sure I will be wishing for this week at PyCon.

At least I’ll be well armed for the next few months, where I’ll be at a number of conferences.

Why I haven’t bought a Kindle

19 Replies

I’m going to spend a significant portion of the next 10 weeks on an airplane or away from home. I also have a large stack of technical papers (in PDF form), and a few books (also in PDF) that I’d like to read. My travel bag is a very decent size, since it has to accommodate camera equipment, so the last thing that I want is to stuff a bunch of paper into it. I would be a perfect candidate for a Kindle.

The Kindle appears to make PDF reading a second (or more like 10th) class activity. E-mailing large PDF files to get them converted to the Amazon format? Sounds very unpleasant to say the least. I’m also not thrilled about the price, the inability to expand storage, or the inability to manage what could grow to be a very large book/document collection.

Kindle lovers, this is your change to speak up and correct my misconceptions, or to confirm them.

Planets, planets, and more planets

3 Replies

Blog aggregators based on the planet software are a staple of open source projects these days. Nonetheless, there are little gotcha’s here and there.

Thom May and I have run the PlanetApache blog aggregator for Apache Software Foundation committers for some time now. It looks like that planet is finally going to move onto official ASF infrastructure where it belongs (in my opinion). If you want a preview, point your aggregator at planet.apache.org/committers. This planet is using Sam Ruby’s refactored planet code, which is known as Venus.

Over in Python land, there are two different and non-overlapping planets: http://planet.python.org/, and http://www.planetpython.org/, as a reader of both of these planets, I would love to see them consolidated so I could stop seeing the articles that are on both planets.

In any case, planets are a great way to get a sense of what is happening in the various communities. If your project doesn’t have one, you should think about starting one. If you have one, make sure it is working super smoothly.