Category "Python"

Early this year, Nokia/Trolltech changed the Qt license from a dual-licensed model (GPL/proprietary) to the more permissive LGPL. But the existing Python bindings for Qt are made by a small company named Riverbank Computing who decided to stick with Qt’s original license.

To fix this, Nokia has launched [PySide]( to make Python bindings available with an LGPL license. From the [ArsTechnica article](

> Python and Qt have the potential to be an extremely compelling solution
> for cross-platform rapid application development. The PySide project will
> address the licensing problems posed by PyQt, but it will also have to
> simplify cross-platform deployment and resolve other technical challenges
> in order to really gain traction.

I developed a GUI using PyQt a few years ago and must say that it was the nicest platform to write a GUI in that I have experienced. Qt has an incredibly rich cross-platform toolkit and Python is a great language to work with. Too bad Nokia could not reach a deal with Riverbank Computing; I can’t imagine using PyQt once PySide is available on all the platforms required.

By the way, part of the PySide project is a [Binding Generator]( which can be used [to generate bindings for *other* high-level languages]( Hmm.

Jacquette Consulting [announced]( [Slither 1.0]( today:

> Announcing the first official release of Slither, the IDL to Python
> bridge. Slither allows Python modules to be used in IDL as IDL
> objects, so you can use the large number of publicly available Python
> modules, and your own Python code, directly within your IDL
> application.

In particular, this caught my attention:

> In conjunction with this release, we’re making a demo version
> available that expires on 10/31/09.

Contact them via email to get a copy of the demo version. The user manual contains a lot of details about the API and is also [available online](

Slither calls Python from IDL. If you need the opposite direction, i.e., calling IDL from Python, try [pyIDL](

[Peter Norvig](, Director of Research at Google, gave the keynote at [SciPy 2009](, [“What to demand from a Scientific Computing Language—Even if you don’t care about computing or languages”](, a conference about scientific programming in Python. His requirements were:

1. *Batteries included* means the standard distribution of the language gives all the tools to do standard things. Here’s where IDL beats Python hands down because the standard distribution of Python is not geared to scientific analysis at all. There are 3rd party distributions such as Python(x,y) or the Enthought Toolkit, but these still need to make progress on ease of install, cross-platform availability, and matching all the functionality of IDL. Of course, Python comes with much greater non-scientific functionality and it is free (as in beer and as in speech).
2. *Expressions, not statements* means the syntax of the language mimics the syntax of mathematics. The vectorized operations of IDL and NumPy in Python go along way here. The garbage collection in Python makes it a bit easier to create objects within expressions instead of creating a variable to contain them so that they can be freed later.
3. *Parallelize* is the ability to use multiple cores. IDL actually uses multiple cores fairly well for many of its core operations, unlike Python.
4. *Documentation, examples, unit tests, tutorials, mentoring* is a mixed bag for both Python and IDL. I think the API documentation for IDL is better than for Python’s scientific routines, but Python has a more active online community (even for just the scientific routines). There are many more resources for core Python.

Norvig worked at NASA Ames and brings his experience of the needs of scientific computing to the [talk](

Randal Schwartz recently gave a talk called “Dynamic Returns” dealing with misconceptions about dynamically typed languages (published as [episode 135]( of the Industry Misinterpretations podcast). His audience for the talk is composed of Smalltalk developers, but the points made are general and equally valid for other dynamic languages like IDL, Python, etc (at least in concept). The six myths are that statically typed languages like Java, C++, and C:

1. reduce development cost
2. increase speed of development
3. eliminate need for some tests
4. improve run-time stability
5. scale better
6. are faster

I agree that the first five points are indeed myths, but I’m not sure IDL has the tools for making IDL as fast or faster than a statically typed language. I know Python has a lot more tools in this area: Pyrex, Psyco, ctypes, f2py, and a bunch more. Of course, there are some things in IDL’s favor: the thread pool automatically uses multiple processors for array operations, there are libraries to make [GPU computing]( and [cluster computing]( easier, and a fairly straight-forward way to extend IDL using C when needed.


The Google Code project [Mail Trends]( visualizes email in any IMAP mailbox (including Gmail if you have set it up for IMAP). It uses a Python interface to the [Google Charts API]( to produce charts of sent and received email organized by time, sender, threads, mailing list, etc.

Link via Information Aesthetics.

Peter Wang of Enthought giving a demo of chaco I got back from [PyCon]( about a week ago. This was the first software conference I have gone to (I haven’t gone to a conference since attending math conferences in grad school). I have been splitting my time fairly equally between IDL and Python recently and the conference really helped me feel more comfortable in Python and the Python scientific community. The conference was more about the Python community than Python itself, but I still got a lot of Python tips out of it.

Continue reading “PyCon 2007.”

« newer posts