On 23/05/13 02:09, boB Stepp wrote:
I would like to ask some general questions here. Problems can arise
from bugs in the operating system, bugs in the programming language(s)
being used, bugs in packages/modules being used, bugs in any third
party packages being used, etc. Also, whenever any one of these things
is updated/upgraded, it can introduce new issues. What strategies can
one use to deal with these possibilities that seem entirely out of the
programmer's control?
They're not really out of your control though. You can always write code
to work around them.
For instance, a long time ago I was using a programming language that had a bug that
caused the program to crash if you tried to display the string "0^0". If this
was Python, I might do something like this:
def my_print(astring):
if astring == '0^0':
# Avoid the system bug.
astring = '0 ^ 0' # Close enough...
print astring
and then make sure I always call my_print instead of print directly.
Sometimes it is sufficient to just avoid triggering the bug. Sometimes you might need use
a different tool. For instance, in Python, print is not "thread safe" -- if you
have two different threads trying to print at the same time, their output may interleave.
# Thread 1:
print "Hello world!"
# Thread 2:
print "Goodbye cruel world :-("
# Output might look like this:
HelGoodblo ye crue l worworldld :-(!
Is this a bug in print? No, not really, but it is a limitation, it is not
designed to be thread safe. So when using threads, you can:
- always make sure only one thread is responsible for doing any printing;
- if you must have multiple threads printing at the same time, use
sys.stdout.write instead of print, because it is thread-safe.
So working around bugs is, in general, possible, even if sometimes it is hard.
A general technique when programming is to always have a good, solid test
suite. This will detect any change in behaviour, whether due to your own
programming errors, on bugs in the language or operating system. What you do is
as you develop your own code, in parallel you also develop a second program
that tests as much of your code as you can.
For instance, suppose you have a (trivial) function that doubles a number and
adds one:
def double_plus_one(x):
return 2*x + 1
So you have a second file open that tests it:
from my_app import *
def test_double_plus_one():
assert double_plus_one(5) == 11
assert double_plus_one(100.25) == 201.5
assert double_plus_one(-0.5) == 0
test_double_plus_one()
(Or you can use a test frame work like unittest or doctest or both.) Now,
whenever you change something, say you upgrade to a new version of the
language, or change your code, you run the test file and see what tests start
failing. Each failed test indicates a bug that needs to be fixed, although it
doesn't tell you what introduced the bug.
--
Steven
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
