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. Rick Richard L. White rlw@stsci.edu http://sundog.stsci.edu/rick/ Space Telescope Science Institute Baltimore, MD