
Hi, 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. Then there is major functionality in IDL that is missing in Python. * (Like plotting. :-) It's hard to translate a routine when you have nothing to translate it to. I've looked at PyDL. It seems a nice little crutch, and it makes the learning curve a little shallower for people converting from IDL to Python. It's very far from being a complete translation from one language to the other. I don't know what Joe had in mind for a converter program. One that took care of braindead syntax conversion, while leaving the more difficult issues for a human programmer to translate, might not be too hard and could be pretty useful. I think it would be a bad idea to hold out for something that automatically produced working code. my $.02 (worth only $0.0127 US) Mark Fardal University of Victoria * I'm stuck in Python 1.5 until the New Year, so have yet to see what SciPy has to offer. Maybe SciPy-Sumo is getting close.

On Tue, 18 Dec 2001, Mark Fardal wrote:
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

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. eric ----- Original Message ----- From: "Rick White" <rlw@stsci.edu> To: "Mark Fardal" <fardal@coral.phys.uvic.ca> Cc: "numpy" <numpy-discussion@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:
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

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. eric ----- Original Message ----- From: "Rick White" <rlw@stsci.edu> To: "Mark Fardal" <fardal@coral.phys.uvic.ca> Cc: "numpy" <numpy-discussion@lists.sourceforge.net> Sent: Wednesday, December 19, 2001 12:30 AM Subject: Re: [Numpy-discussion] converting IDL to python
participants (3)
-
eric
-
Mark Fardal
-
Rick White