You can hardly be an astronomer today without knowing how to write code. As with programmers in all disciplines, we are at the mercy of the language we code with. Computer science is still a rapidly evolving field and new programming languages come along, existing programming languages get updated, and your favorite packages/routines might get deprecated or de-supported all together. Whether you stick to your old favorites or jump-ship to the latest and greatest seems to be a matter of personal taste.
The python programming language is still fairly new to astronomers; but it has many advantages over C/Fortran/IDL (and some disadvantages, see here for our wiki page on Python v. IDL). In many scientific research fields, python has been adopted very rapidly. However, the python programming language has undergone a major overhaul going from 2.* versions to 3.* versions. The most common scientific python packages still use 2.* versions; but, rumblings have begun to migrate them to 3.* versions in the near future. I expect it will still be a a year or two before 3.* support in numpy, scipy, and matplotlib python packages are fully supported and de-bugged and I would imaging that 2.* support will continue for the next 5-10 years at least. But I still use codes written over 20 years ago, so long-range planning isn’t completely crazy.
For your early adopters out there, here is a useful quick-switch guide for python 2 to python 3 conversions. I should note that python 2.6 and 2.7 have transitional support for features found in python 3.*; but there are still some differences. Since python 2.7 comes installed with OS X Lion, if you get a new machine or upgrade, then consider tinkering with the new python features. And take a look at which of your coding habits will break things in the future. For instance:
print 'I found %10d bugs' % bugCnt
doesn’t work in python 3 and instead should be replaced with
print('I found {:10d} bugs'.format(bugCnt))
Here are a couple of other relevant links.
I can’t resist mentioning that I use a Fortran subroutine written almost 50 years ago on punch cards that runs just fine on my 2011 Mac and Intel Fortran. There is a place for both languages of course but I think Fortran will be with us for a long time. Churning like this will not facilitate widespread adoption of python.
? “churning”
Product churning: “…the business practice whereby more of the product is sold than is beneficial to the consumer.”
Really? I think its sort of brilliant that Python has taken the approach of having parallel 2.X and 3.Y tracks that include transition tools (2to3, from future) so that the user is conditioned to evolve with the language.
In fact conditioning scientists that scientific computing as part of their research skill set includes utilizing multiple computer languages to find the one that best suites the problem at hand and that language evolution should be accepted if not embraced is so important that its one of the reasons I end up advocating for python and against “f77”.
Jessica,
Think both of these statements are pretty problematic (and I think my extraction of them is also consistent with your intent but correct me if I’m wrong):
I think the conditions these statements imply — “the” language we use is singular and that we fall back to familiarity when approaching a computing problem — belie the problem that scientists’ computer science skill sets are quite limited even if we do “know how to write code.”
So my rendition of ‘danger will robinson, 2to3 is happening’ isn’t that changes are going to happen (since this is normal) but that the timescale for 2to3 to reach throughout numpy, scipy, and matplotlib is very very unclear.
The most recent versions of Numpy (1.6) and Scipy (0.9) are compatible with Python 3. Matplotlib will be compatible in one release or so (https://github.com/matplotlib/matplotlib-py3/wiki).
The old formatting syntax will also still be valid in Python 3. So you can still use ‘I found %10d bugs’ % bugCnt instead of the new ‘I found {:10d} bugs’.format(bugCnt).
But I would say python 2.x will be around indefinitely, so there’s no big rush to to worry about this now.
Could anyone recommend a good Python book for beginners? Are there any geared towards “scientists & engineers” rather than computer science?
Thanks
For $29, you can’t go wrong with Learn Python the Hard Way http://www.udemy.com/learn-python-the-hard-way/ . It has a book, videos, and an active threaded discussion group on each lesson.
We have some good links to tutorials on our Python wiki page:
https://www.astrobetter.com/wiki/tiki-index.php?page=python
OK! I confess I have never used programming for astronomy and I have always been studying astronomy! I guess I’m one of those rare spices that like to build stuff 🙂 but for better or worse, I need to write a pipeline to reduce my instrument’s data and that’s why I’m here! Thanks for the useful information… I’m going to go with Python 3 and hopefully everything goes well
I don’t know if anyone’s already been able to transition properly, I myself started on Python3. Would anyone know how to format a bit of code for me from Python2 to Python3? I was unable to access my python application, so I used an online compiler, not knowing IT was writting in python2.
print (“Loading”),
time.sleep(2)
print (“.”),
time.sleep(1)
print (“.”),
time.sleep(1)
print (“.”),
time.sleep(1)
In short, the code above is supposed to look like this:
(Loading.)(Loading..)(Loading…)
with each parenthetical value being the same statement with the “.” added to the end. The trouble I’m running into transitioning this is that the time.sleep(1) is interrupting it, forcing the next print onto a separate line, which is NOT what I want. Any feedback or commentary on fixing the issue would be much appreciated.