A Meteorologist’s Road to Python (Part 1)

Editor’s note: In this post, Associate Professor of Meteorology Alex DeCaria of Millersville University shares about his experiences with using and learning computer languages (Fortran, IDL, Ruby) for use in meteorology, how he came to discover Python, and why it is useful for his work in the atmospheric and oceanic sciences. In Part 2, Alex discusses specific features of Python that he loves, as well as one caution about using Python 3 vs. Python 2.7. If you have comments, please feel free to email him at alex.decaria@millersville.edu.

Well into the 1990’s I assumed that I would never need any other programming language besides Fortran, especially when I made the transition from Fortran 77 to Fortran 90. “I don’t have to worry about starting statements in column 7? Is this Heaven?” I also discovered IDL in the 90’s, although I primarily used it to visualize data that I had previously generated using Fortran. When a colleague who had been teaching our IDL class retired, and I was the only other person in our department with experience in IDL, it fell upon me to teach the IDL course. This is when I truly learned that IDL was so much more than just a visualization tool, and it quickly became my language of choice.

However, I also felt the urge to explore an object-oriented programming language. I wanted something more modern than either Fortran or IDL. I first chose Ruby and immersed myself heavily, learning everything I could about it; my shelf of Ruby books expanded exponentially. I loved the natural and flexible syntax of Ruby, and quickly began writing scripts to do everything from creating GUI’s (using the Ruby Tk library) to automating Excel, Word, Outlook, and other MS Office products. (I even wrote a script for automatically generating letters of recommendation for students, which I could then edit and personalize – my true confession). Although writing a script in Ruby is relatively straight-forward, getting Ruby installed with all the proper external libraries and dependencies was not. I also was unable to find a satisfactory plotting library in Ruby, so I still needed to use IDL for any serious scientific calculations and plotting. Development within the Ruby community seemed disjointed and did not progressing smoothly. I had little confidence that a library that I might choose to use would continue to be supported. This became very apparent when I made the switch from an older version of Ruby to the much touted Ruby 1.9, and tried to get my RubyTk scripts to work. At first they wouldn’t work at all, and after much searching and dialoging on the Ruby forum I managed to get them to work – but they were excruciatingly slow to load! Abandoning RubyTk I searched for a different GUI library and found FXRuby. This looked extremely promising, and so I invested much time in learning FXRuby and rewriting my GUI scripts from RubyTk. Within months after I finished, the developer of the FXRuby library unexpectedly ‘pulled chocks’ and abandoned the project (after having written a reference book on it only a year or two before)! (Of course, this is always the danger with relying on open-source libraries.) This was the last straw!

Enter Python. About this time I had began hearing about how Python was rapidly gaining a following in the science community. It seemed to have more support in the community than Ruby, and development seemed to be on a firmer footing. After attending the Python short course at the 91st AMS meeting I made a decision to try Python. In less than three months it has become my new favorite (and likely last) programming language. Python possesses all the factors that I really liked about Ruby. Its syntax is clean and intuitive, and makes writing programs fun. But, even better than Ruby, Python comes with many standard libraries that are built-in and work right out of the box, without downloading extra modules and worrying about dependencies. The Enthought Python distribution installed and worked flawlessly on the first try! With my prior experience with Tk I was easily able to write GUI’s using Python’s Tkinter library.

Unlike Ruby, I can see Python (with the Numpy/Scipy and matplotlib libraries) as taking the place of IDL for my scientific computations and plotting. I have rewritten several plotting programs from IDL to Python, using the matplotlib library, and am much happier with the quality of the plots I am getting compared to IDL. Two examples of plots created using Python and matplotlib can be found on my university’s website. One is a twenty-four hour plot of weather data from our weather station. The other is a monthly temperature climatology plot.

Why am I so excited about using Python in my work? When it is combined with Numpy/Scipy and the matplotlib plotting library, Python is a very capable and FREE substitute for IDL. My university teaches a class in IDL that has been required of all of our meteorology undergraduate students. However, only a small group of those students will move on to jobs or schools that have an IDL license. The rest will likely never be able to use it again. So, all the cool things I teach them about IDL will go unused by most of the students. If I teach them Python, they will ALL be able to use it no matter where they go.

Python is modern and easy to learn. I picked up Python very quickly, and though I have been programming for over 30 years I think that Python is also an easy language for a beginner to learn. The syntax is clean, and makes sense! I especially love not having to include semi-colons, curly braces, or an end statement at the end of every block of code. The indentation does it all! How much more simpler can it be?

Finally, Python seems to be better supported and have more momentum in the science community than does Ruby, and has more built in libraries. And, the libraries seem to load and work with minimal errors. Though there are some very savvy Ruby developers, and some clever libraries, my sense is that Python development is on a firmer footing and is more robust. I have more faith in Python libraries sticking around and being supported than I do Ruby libraries.