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.

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.

Here are the some thoughts on the major activities of the conference:

1. The tutorials before the conference were great. I took a session on optimization and one on the “idioms” of Python. As a newcomer to Python, seeing the idioms that experienced Python programmers used to do common operations was extremely valuable.
2. The keynotes had an educational theme (except for Guido’s talk about Python 3000). I especially enjoyed Robert M. “r0ml” Lefkowitz’s talk about “Computer Literacy” (he defines it in quite a different way than in most uses of the term). As someone who freaks out when I hear about school children learning to make PowerPoint presentations, this was great.
3. There were a three sessions of talks going all day long. There were a few geared specifically to science, but there were many general purpose talks about topics that I will need to use and many more about ideas that I might need to use.
4. There were “birds of a feather” sessions where people interested in a particular topic get together and discuss their area. These are usually held at night after the talks.
5. I didn’t go to a lot of the lightning talks sessions because I usually went to dinner about then. (Lightning talks are limited to five minutes and are selected in a much more informal manner than the main talks.) The two sessions I went to were pretty good though.
6. I went to several vendor demos by Enthought. They showed off their tools pretty well. I am definitely thinking about using their traits package with VTK (and maybe dumping matplotlib for their chaco too). I need Qt bindings for their stuff to do that, though. All kinds of ideas pop into my mind at this point.
7. I think for most of the participants, the main advantage is meeting people in person that they may have interacted with online extensively. Since I just lurk on the mailing lists and usenet group so far, I didn’t really “know” anyone, but I had seen a lot of peoples names before. I also met several people from Boulder.
8. I didn’t participate in the sprints at the end of the conference. Sprints allow developers to concentrate their efforts for a few days on solving some issue in an environment where they can get people together face-to-face.

There is definitely a community in the open source software community. So many of the activities were geared towards community participation, especially the birds of a feather sessions and the sprints. People with a common need frequently collaborate to create a project that will satisfy the need.

One final thought: it seemed like every company represented was hiring Python programmers. It was a running joke throughout the conference.