Python Success Stories or Nightmares
geoff at gerrietts.net
Fri Jan 31 01:16:45 CET 2003
Quoting Mongryong (Mongryong at sympatico.ca):
> Let's hear people's success stories with Python and why they did the
> switch. Or, tell us about you're Python nightmare and why you're still
> questionable about the language as more than a 'glue' language.
I work at a firm with a couple hundred thousand lines of Python
running our app. Here's a quick summary of the good, the bad, and the
Before I start, let me note that "any other language I've worked in"
refers to C, Objective C, Java, C++, and Perl. I suppose you could put
shell or awk or sed in there too, but I don't really consider them
programming languages; any real programming I've done in shell
qualifies as accidental.
- We deliver product religiously every 2 weeks, and sometimes every
week. We deliver substantial products in a fraction of the time it
would take to develop in any other language I've worked in.
- The resulting code is extremely readable, even when written by
gurus, or when written by rank novices. Maintaining another person's
code is very easy, especially when compared to maintaining another
person's code in pretty much any other language I've worked in.
- The code platform is very stable. Defects have only once or twice
been attributable to python or the extensions we use, and even those
issues have been pretty minor.
- The code is very flexible. Our business changes with the passing
breeze (the breaking wind?), and the code changes to meet the latest
and greatest expectations. We've had very good results refactoring
existing software to new uses.
- Unit tests are amazingly easy to write, since you can "stub in"
dependencies in lots of different ways.
- A couple hundred thousand lines of Python doesn't always run as fast
as you might like. We spend a decent amount of time trying to
identify and remove bottlenecks. We have met with varying degrees of
- Everything happens at runtime, so typos in infrequently-used code
paths can still yield runtime errors. I think pychecker would
alleviate some of this trouble, if pychecker worked more cleanly
with our code.
- No stand-alone profiling. No external debugging. To us, this has
meant that it's somewhere between difficult and impossible to attach
a debugger to much of our running code; it all runs inside a
threaded server context that does not permit straightforward use of
the debugging and profiling modules.
- Despite the ease of writing tests, I'm pretty much the only one in
the office who believes in them, and that presents a Herculean
challenge every time I set out to write a test battery. Meanwhile,
the tests will not be updated when the code changes, so we have that
particular cross to bear. Or I do, at least, everyone else seems
largely unaware of the large wooden structure on their shoulders.
- We've encountered resistance when trying to move forward to newer
versions of the app server, the python language, the operating
system, and other dependencies. It takes enough changes to various
pieces of our system that it requires a substantial investment of
migration time, and last time we got close to a working version, the
plug was pulled on the project before it got into testing. This is a
consequence of organizational laziness (we haven't kept up), some
lack of a solid business case (things are working, and convenience
of development is hard to gauge), and partly the open source shuffle
(where every piece has a dependency on some particular version of
some other thing).
> I for one would like to know, if anyone has written a 'real' compiler
> for Python like "jcc" is for Java? What are some of the difficulties in
> writing such a compiler (type-checking and dynamic importing to
I think Psyco is as close as anyone's come to date, though I've heard
some discussion around the fringes indicating interest. No real
Geoff Gerrietts <geoff at gerrietts dot net>
I AM YOUR KING! BOW BEFORE ME, PEASANT! -- Dogbert
More information about the Python-list