Google + Python = world domination?

Since its initial release in 1991, the Python programming language has steadily grown in popularity. Designed by Dutch programmer Guido van Rossum (a.k.a. Python's Benevolent Dictator for Life), its conciseness, power, flexibility, portability, and large ecosystem of readily available libraries have gained it many converts. Today it is used in a wide variety of diverse environments—Google is powered by Python, as is the popular Web development framework Zope. On UNIX/Linux it is also viewed by many as a modern replacement for Perl, which has historically been the "heavy lifting" scripting tool on those platforms. Where I work, we use Python for a wide variety of intraweb, scripting, and automation tasks, including a large regression testing framework we use to test our software.

Python is not without its issues, however. The most widely deployed implementation is interpreted (i.e. it doesn't compile all the way down to native machine code), which has significant performance implications. It also does not handle multithreaded code well, since parts of the Python interpreter are inherently single-threaded. Python's lack of full multithreading support has become increasingly problematic as multi-core CPUs have become the norm. Developers have typically worked around these limitations by coding performance-critical portions of the application in C or C++; the compiled C/C++ code is then called by the Python script. While certainly workable (and well supported by Python), this approach increases development times, complicates debugging, and hurts portability of high-performance Python applications.

Fast-forward to 2009. Guido is now a Google employee, and a team at Google has decided to take on the ambitious task of replacing much of the underpinnings of the Python language, with the goals of removing the interpreter performance bottlenecks and making true multithreaded Python applications possible. All without hurting backward compatibility with existing Python applications... a rather tall order! The project is code-named Unladen Swallow, and the team already has a detailed plan outlining its intended approach, which will occur in stages.

By mid-year, they intend to replace the existing Python interpreter with a more efficient one based on LLVM. This has some immediate benefits—eliminating the relatively inefficient stack-based architecture of the current Python interpreter with the more efficient LLVM register-based architecture should result in significant performance gains. Longer term, it paves the way for compilation to optimized native machine code, which has the potential to make Python performance comparable to that of other languages that compile to native machine code (like C/C++). Once the transition to LLVM is complete, the team plans to tackle other optimizations and enhancements, including the multithreading issue.

Speaking as a long-time (quarter of a century!) C/C++ developer and relatively recent convert to Python, I find the Unladen Swallow project a very exciting development. If successful, I believe it will position Python to compete directly with C/C++ in the systems, applications, and gaming markets. It could also accelerate Python's displacement of other scripting languages like Perl and PHP in the server infrastructure and Web application markets. Furthermore, the portability of Python (and its supporting libraries) has the potential to make it much easier for developers to port applications between platforms: moving apps between Windows, Mac OS, and Linux could literally become as simple as recompiling a set of Python modules. If Unladen Swallow pans out, I think it is entirely plausible that, in the not-too-distant future, we could even see a commercial cross-platform FPS game implemented entirely in Python—something that would be unthinkable with the current Python implementation.

Kudos to Google for its willingness to fund R&D efforts to improve a technology that has the potential to benefit everyone!

Tip: You can use the A/Z keys to walk threads.
View options

This discussion is now closed.