Python hits the spot

Christian Tismer tismer at
Sat Jun 22 18:17:38 EDT 2002

Siegfried Gonzi wrote:
> Bengt Richter wrote:
>> Have you never chased a bug that only shows up in secondary effects?
>> In C code, the most common way for that to happen is storing something
>> through a bad pointer, but instead of getting a memory fault, it corrupts
>> some data structure or data value. The value could be used 20 minutes 
>> later
>> and cause GPF then, or e.g., it could be data that's part of a 
>> calculation,
>> but maybe it's only overwriting the least significant half of a floating
>> point number, so you get the effect systematic bias or random error 
>> injected
>> into your calculation, but nothing else. If you don't look for 
>> explanations
>> of last-decimal errors, this kind of thing can persist a long time. OTOH,
>> you could be corrupting numbers that are used in an iterative calculation
>> that mysteriously starts to take longer to converge, and does so in a 
>> systematically
>> increasing way, because the corrupting data varies systematically with 
>> time.
>> Or you could be corrupting data structures and sabotaging memory 
>> management
>> without causing immediate GPF, etc. etc.
> The explanation is good and could explain the bad behavior. But note: I 
> use the same C code on Windows and on Linux! On Windows I used SWIG and 
> Visual C++. On Linux I used gcc and SWIG.

So what?
You get similar behavior under Windows and Linux. The program
goes astray. Windows can kill the job. Linux can, too; you are
just not used to Linux.
How the program misbehaves is surely slightly different due to
different OSes and compilers.

But you tend to draw conclusions from nothing.
Using the same tool (Python) on different machines
with your programs gives you crashes. That makes you
damn the tool.

The first one a programmer should never trust is yourself.
If you count the errors and crashes of your life's
programming, you will have to conclude that most of the
time it is *you* who makes errors. This is fine, since
everybody has this problem.
But your program has only undergone your own testing, while the
tools you are using are well-approved hundreds of thousands
of times. They have grown the same way as your own stuff, but
they had orders of magnitude more chances to ripen.

Please keep that in mind, whether you leave Python and stick with
F90 or not. F90 has bugs, and Python has, but before searching
for them, it is much more efficient to look for your own.

> Theoretically I could do the following: trying to use the Fortran code 
> instead of the C code. The C code relies on a Fortran 77 code. I pinched 
> the C code from the netlib (or so). But I could try to use F2PY in 
> combination with the Fortran 77 code.
> The F2PY would have the advantage that I am not forced to write 
> explicitely pointer-wrapper functions in Python in order to use the code 
> which comes from SWIG.

This might in fact be simpler.
What I'd like to suggest:
Go through you code and add comments. Think that you
have to explain your code to somebody who has no idea
about it at all. Then, give it realy to a colleague,
let him read the code and ask questions. Explain everything,
and defend every line of your code. Why is it so and not
different, what is the reason ebhind this, what happens if
that condition isn't met -- oops, I didn't check. ???

You will find the bugs, finally, probably also those, which
are nicely hiding in the original code for a long time.

> The above could also explain why under Windows the system sucks down, 
> but it is not destroyable!

Run it under restricted resources with Linux, and you will
be able to kill the job, too.
Or just stick with Windows. The problem is not the OS!

or-make-me-an-offer-to-solve-this-for-you - ly y'rs - chris

Christian Tismer             :^)   <mailto:tismer at>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship*
14109 Berlin                 :     PGP key ->
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?

More information about the Python-list mailing list