[SciPy-dev] implementing IDL, Matlab, etc. functionality
jh at oobleck.astro.cornell.edu
Mon May 2 11:40:44 CDT 2005
> Personally, I don't thinks this is a good use of manpower. matlab and
> IDL are both pretty crappy languages. That's why people don't want to
> use them.
I'll appeal to my extensive, if informal, surveys of the astronomy
community. A lot of us have a lot more than just 8 years of code we
depend on, and simply cannot switch until we can convert our most
important codes. For example, several of the packages I now depend on
for my research took me and about half a dozen students years of
full-time work to write. Most of those students are now gone. I use
these packages every day. I'd have to get new grants specifically to
hire and supervise more students just to redo them so that I could do
my daily work. That isn't going to happen, and I'm far from a unique
case. You can tell us to go jump in a lake if you like (which you
basically just did). Instead, we're going to take care of our own
problem, and hopefully that of a lot of others.
My goal is not to make IDL-in-python (gnudl tries, as does octave for
matlab, both badly, as you note). It's to facilitate the conversion
of code to Python. We can do an 80% solution without a great deal of
effort. The idea is to create a code converter that would handle all
of the procedural syntax, and which would flag in loud comments the
things it couldn't do. Then the user would hand-code the remainder.
We would not have a function compatibility library, though we could
rig a way of describing the most common functions so that it could
convert the calls for them. Nobody could possibly have an expectation
that the code produced this way would run unmodified, so I don't think
we'll make unsatisfied users. Rather, I think just the opposite: this
package will be a great relief to many, as will its Matlab equivalent.
My main concern is not for coding labor but rather for numerical
accuracy. There are enough subtle differences between Python and IDL
that hand-converting large amounts of numerical code would be
error-prone. For example, in Python the end of an array slice is one
element beyond the end of an IDL slice. An automatic converter would
just add one to every slice's ending index. A human wouldn't
necessarily remember to do that every time, producing subtle bugs
could be very hard to find in some cases.
More information about the Scipy-dev