Re: exception and error handling
And yes, Tim: Python is vastly better that Fortran, C, etc...
It's just that I'm such a Python FAN that my expectations are
ALSO vastly higher. Also - I enjoy pushing at the edges and
finding out what I CAN'T do. What is FUN, is when you discover
that things are easier that you had thought.
Which brings me to "Stupic Python Trick #2" :
I often find myself creating pieces of python code with this idiom:
list =  # start with empty list and fill it
while Something :
list.append( next_thing() )
string = '' # start with empty string and fill it
string = string + next_token()
Sometime I find that I'm creating a what could be a generic
function that operates on sequences, but I needed ( or at
least wanted ) the function to return the same type of
sequence that it had been given. I couldn't figure out a
good way to do this, other than checking the type of the
args and doing some conditional processing according to
the type. But, now, with the ability to create new classes
of sequences, that solution is even less satisfactory.
Luckily, however, a description of one aspect of the
problem points to the solution.
Note the relation:
type( string ) == type( string )
type( list ) <> type( list )
type( tuple ) <> type( tuple )
i.e. Strings are composed of smaller strings,
But tuples and lists contain other things.
However, the relation that IS consistent is:
type( sequence ) == type( sequence[:0] )
i.e. sequence[:0] is the empty sequence for all sequence types.
Which gives us the idion in the following example:
( pace SICP, for the "iterative" recursive function. )
def reverse( thing ):
return revi( thing, thing[:0] )
def revi( a, b ):
if not a : return b
return revi( a[1:], a[:1]+b )
string = '123456789'
list = [ 1,2,3,4,5,6,7,8,9 ]
tuple = ( 1,2,3,4,5,6,7,8,9 )
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[9, 8, 7, 6, 5, 4, 3, 2, 1]
(1, 2, 3, 4, 5, 6, 7, 8, 9)
(9, 8, 7, 6, 5, 4, 3, 2, 1)
and should do the same for any user-written, sequence like class.
I expect that this momentous discovery is actually burried somewhere
in the sources of one of Guido's demo scripts. Well - maybe if we
trade some of these simple idioms, I can remind myself that python
is NOT C,LISP,Pascal,ICON,Perl, or any other language, and stop
complaining about functions vs procedures, etc. Maybe we a creative
challenge to see how many different ways we can find to write a
simple python program - sort of like the 4000 different ways to
print "Just another PERL hacker" that you always see in the sigs
[ 'Hacker', 'Python', 'another', 'Just' ].reverse()
!!! OOPS !!! - It didn't print anything! - Steve