[Numpy-discussion] converting IDL to python

eric eric at enthought.com
Thu Dec 20 08:36:03 EST 2001

I'm not an IDL user, but have thought some about the same sort of project
for either executing Matlab scripts from Python, or perhaps translating them
to Python.  On the face of it, it seems doable.  Of the incompatibilities
I've thought about, the magic NARGOUT variable that tells Matlab how many
output results are expected from a functions seems the most difficult.  It
might be handled in Python by examining the parse tree, but it isn't a
trivial translation.

Another option would be embedding Octave which is a Matlab work alike.  I
think it is a little behind the current Matlab release though.

There might be some synergy between projects aiming to execute IDL/Matlab
code from Python.


----- Original Message -----
From: "Rick White" <rlw at stsci.edu>
To: "Mark Fardal" <fardal at coral.phys.uvic.ca>
Cc: "numpy" <numpy-discussion at lists.sourceforge.net>
Sent: Wednesday, December 19, 2001 12:30 AM
Subject: Re: [Numpy-discussion] converting IDL to python

> 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
> >   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
> 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.
> Rick
> Richard L. White    rlw at stsci.edu    http://sundog.stsci.edu/rick/
> Space Telescope Science Institute
> Baltimore, MD
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list