[Numpy-discussion] converting IDL to python

Rick White rlw at stsci.edu
Tue Dec 18 21:31:06 EST 2001

On Tue, 18 Dec 2001, Mark Fardal wrote:

> earlier this month Joe Harrington posted this:
>   NASA's immediate objective will be a complete data-analysis system to
>   replace IDL, in short order, including an IDL-to-python converter
>   program.  That shouldn't be hard as IDL is a simple language, and PyDL
>   may have solved much of that problem.
> I'm an IDL user, and I'm currently trying to see if I can switch over
> to python.  It strikes me that an IDL-to-python converter program is a
> VERY ambitious idea.  While IDL's syntax is rather similar to Python,
> and less powerful (so that there is less to translate), there are
> enough differences between them that conversion is probably not a
> simple task.  For example, in IDL:
>   arguments are passed by reference
>   array storage order is different
>   there's a different notion of "truth" than in Python
>   a structure type exists, and a notation for slicing arrays of structures
>   trailing "degenerate" array dimensions are truncated in a hard-to-predict way
>   array subscripting generates copy, not reference
> I'm sure there are some other big differences too.  

I'm thinking about this problem too.  For the PyRAF system
(pyraf.stsci.edu), I wrote a set of Python programs that parse IRAF CL
scripts and automatically translate them to Python.  CL scripts have a
much less regular syntax than IDL (making them harder to parse), but the
CL has a vastly more limited functionality (making it easier to translate
the results to IDL.)  I did have to deal with issues similar to those
above.  E.g., the CL does pass arguments by reference (sometimes -- I told
you it is irregular!) and I figured out how to handle that.  The array
storage order doesn't strike me as a biggie, it is just necessary to swap
the order of indices.  The CL also has a different notion of truth
(boolean expressions have the value yes or no, which are magic values
along the lines of None in Python.)  The IDL notion of truth is really
pretty similar to Python's when you get down to it.

The new numeric array module that we have been working on (numarray) also
supports the equivalent of arrays of structures that can be sliced and
indexed just like arrays of numbers.  We had IDL structures (among other
things) in mind when we developed this capability, and think our version
is a significant improvement over IDL.  We also have arrays of strings
and aim to have all the basic array functionality that is available in
IDL.  (By the way, I'm a long-time IDL user and am reasonably expert in it.)

The hardest part (as you mention) is that IDL has a really large
collection of built-in functions which probably will not be readily
available in Python.  Until someone writes things like the morphological
dilation and erosion operations, it won't be possible to translate IDL
programs that use them.  And there will always be some weird corners of
IDL behavior where it just would not be worth the effort to try to
replicate exactly what IDL does.  That's true in the CL translation too
-- but it does not seem to be a big limitation, because users tend to stay
away from those weird spots too.

My conclusion is that an automatic conversion of (most) IDL to Python
probably can be done with a reasonable amount of work.  It certainly is
not trivial, but I think (based on my experience with the CL) that it is
not impossibly difficult either.  I'm hoping to take a shot at this
sometime during the next 6 months.

Richard L. White    rlw at stsci.edu    http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD

More information about the NumPy-Discussion mailing list