IDL is widely used in the astronomy community with rich libraries of astronomy specific programs and applications. More recently, Python has rapidly gained support with development of astronomy software for Hubble and James Webb space telescopes and ALMA all utilizing Python. For astronomers considering switching from IDL to Python, or choosing one or other for the first time, a comprehensive guide of pros and cons was originally published by Greenfield and Jedrzejewski (see the AstroBetter blog entry on IDL vs. Python for the full excerpt).
Below, we keep an updated pros and cons list. Some points may be up for debate, but all debate should be kept to the comments section of this page.
Pros of IDL
- Many mature numerical and astronomical libraries available. e.g., Astro Library
- Wide astronomical user base
- Numerical aspect well integrated with language itself
- Many local users with deep experience
- Faster for small arrays
- Easier installation
- Good, unified documentation
- Standard GUI run/debug tool (IDLDE)
- Single widget system (no angst about which to choose or learn)
- Use of keyword arguments as flags more convenient
Cons of IDL
- Narrow applicability, not well suited to general programming
- Slower for large arrays
- Array functionality less powerful
- Table support poor
- Limited ability to extend using C or Fortran, such extensions hard to distribute and support
- Expensive, sometimes problem collaborating with others that don’t have or can’t afford licenses.
- Closed source (only RSI can fix bugs)
- Very awkward to integrate with IRAF tasks
- Memory management more awkward
- Single widget system (useless if working within another framework)
- Plotting: much improved with the new graphics system in v8.0
Awkward support for symbols and math text Many font systems, portability issues (v5.1 alleviates somewhat) Not as flexible or as extensible Plot windows not intrinsically interactive (e.g., pan & zoom)
Pros of Python
- Very general and powerful programming language, yet easy to learn. Strong, but optional, Object Oriented programming support
- Very large user and developer community, very extensive and broad library base
- Very extensible with C, C++, or Fortran, portable distribution mechanisms available
- Free; non-restrictive license; Open Source
- Becoming the standard scripting language for astronomy
- Easy to use with IRAF tasks: PyRAF
- Basis of STScI application efforts
- More general array capabilities
- Faster for large arrays, better support for memory mapping
- Many books and on-line documentation resources available (for the language and its libraries)
- Better support for table structures
- framework (matplotlib) more extensible and general
- Better font support and portability (only one way to do it too)
- Usable within many windowing frameworks (GTK, Tk, WX, Qt…)
- Standard plotting functionality independent of framework used
- Plots are embeddable within other GUIs
- More powerful image handling (multiple simultaneous LUTS,
- Optional resampling/rescaling, alpha blending, etc)
- 3D plotting via matplotlib.mplot3d (simple) or Mayavi2 (full-featured) blog post
- Support for many widget systems
- Strong local influence over capabilities being developed for Python
Cons of Python
- More items to install separately
- Not as widely adopted in astronomical community (but support clearly growing)
- Scientific libraries not as mature:
- Documentation not as complete, not as unified
- Not as deep in astronomical libraries and utilities
- Not all IDL numerical library functions have corresponding functionality in Python
- Some numeric constructs not quite as consistent with language (or slightly less convenient than IDL)
- Array indexing convention “backwards”
- Small array performance slower
- No standard GUI run/debug tool
- Support for many widget systems (angst regarding which to choose)
Current lack of function equivalent to SAVE/RESTORE in IDLCan be done with cPickle matplotlib does not yet have equivalents for all IDL 2-D plotting capability (e.g., surface plots)now possible in 0.99
- Use of keyword arguments used as flags less convenient
Specific cases where using Python provides strong advantages over IDL
- Your processing needs depend on running a few hard-to-replicate IRAF tasks, but you don’t want to do most of your data manipulation in IRAF, but would rather write your own IDL-style programs to do so (and soon other systems will be accessible from Python, e.g., MIDAS, ALMA, slang, etc)
- You have algorithms that cannot be efficiently coded in IDL. They likely won’t be efficiently coded in Python either, but you will find interfacing the needed C or Fortran code easier, more flexible, more portable, and distributable. (Question: how many distributed IDL libraries developed by 3rd parties include C or Fortran code?) Or you need to wrap existing C libraries (Python has many tools to make this easier to do).
- You do work on algorithms that may migrate into STSDAS packages. Using Python means that your work will be more easily adapted as a distributed and supported tool.
- You wish to integrate data processing with other significant non-numerical processing such as databases, web page generation, web services, text processing, process control, etc.
- You want to learn object-oriented programming and use it with your data analysis. (But you don’t need to learn object-oriented programming to do data analysis in Python.)
- You want to be able to use the same language you use for data analysis for most of your other scripting and programming tasks.
- Your boss makes you.
- You want to be a cool, with-it person.
- You are honked off at ITT Space Systems/RSI.