Does Python seem appropriate for me?

[Tim Peters]

[Rick Olson]
> I'm doing some research developing some algorithms for solving
> scheduling problems.  In the past, I have done most of my work
> using MS C/C++ v. 7 or the Watcom compiler on a PC because I
> could run the result in a DOS environment making it easy to write
> big batch files and run comparisons to other code on a system
> with little system overheard.  I am now getting ready to start
> a new project.  WIN2k has eliminated DOS from my list of options,

I don't understand that part.  You can not only run in a DOS box under Win2K,
but Win2K's emulation of a DOS box is much more capable than DOS's ever was.

> so I thought I'd take the plunge into Linux.

Provided you can get over the initial hump, you won't be sorry.  "Provided"
means that, while Linux is a much better development environment once you
know what you're doing, *getting* to that point is a loooong journey.  Even
the littlest things will drive you mad.  Trivial example:  say you use

    dir/s *.py

today to find all the .py files in the subtree rooted at the current
directory.  You're not going to *believe* the hoops you have to jump through
to get that done under a Unix shell instead.  If you have someone around to
*show* you, cool, they'll rattle it off from memory; else you're going to
spend a frustrating hour staring at the "find" man page, provided you're
lucky enough to guess that's where you have to look.  In the end, Unix "find"
is much more powerful than DOS "dir", but at the start it can be overwhelming
("find" implements a full-fledged "little language" for file identification,
complete with boolean operators and a hokey notion of control flow:  figuring
out which of the 50 pieces you need-- or even recognizing that they're
relevant! --is simply a challenge at first).

> The work has essentially three parts:
> a) Conceptual developing/coding algorithm
> b) Tuning algorithms to get good performance
> c) Running comparisons against algorithms developed by other people.

Python is (IMO) the best language in the world for #a.  I've often researched
algorithms in Python that colleagues were researching in C or C++, and in the
time they could get one partly-working revision finished, I was able to fully
code, test, and throw away 5 fundamentally different approaches.  As a
result, in the end I've often had a Python program to solve a difficult
problem that ran 100x faster than their C or C++ code!

Their problem is that it's so painful to rearchitect when the code is
long-winded, and so depressing to throw away veritable mountains of source
code, that they settle for *tweaking* their initial approach even when their
intuition eventually tells them that a different approach altogether *may* be
a big win.  In Python, you don't hesitate:  you just *try* the different
approach and see what happens.  If it doesn't pay off, no big deal, it wasn't
a soul-crushing effort to work up anyway.

Python is less suitable for #b if the end result is *going* to be rewritten
in another language.  Fine-tuning Python code for speed doesn't have any
direct relationship with what you need to fine-tune C or C++ code for
speed -- the  implementations are radically different, so the pragmatics are
radically different too.

For all the rest I defer to a GUI Guy <wink>.