But a Class is just *supposed* to be THAT TYPE of interface.
A class method get's it's arguments ( except for "self" )
from "outside". So there are TWO types of error messages:
"Something unexpected happened - This class is broken!"
- stack trace and other interesting stuff for the implementor
(or re-implementor or maintainer) of that class.
[for the Class programmer]
-OR-
"You are giving me garbage! - please read the instructions on
how to use this class and/or method."
[for the Class end-user]
That's largely what OO-design/programming is all about: (isn't it?)
The distinction of inside/outside on many different levels;
black boxes, interfaces, etc. The programmer IS the end
user - of a Class.
[ <unrelated-digression-about-error-handlers>:
One of the things I used to like about VAX/VMS exceptions was
that they also had levels of severity: (Info,Warning,Error,Severe )
and you could raise/catch/ignore signals of a specific level.
So instead of using a debug or verbose flag, you would just
lower the severity level to catch and report warnings. But the
exception handler had a different model than python - after
catching a exception signal, you could examine it, and return
to the site of the exception - which is exactly what you would
want to do for warnings and informational messages. Or re-raise
the exception for more uplevel processing. ]
- Steve M.
BTW: there are a few bugs in my IStream Class. It passed
the tests OK on small files, but accessing stream[indx]
before the buffer is loaded by some other access seems
to make it try to read in the whole file ( which is
quite noticable when you try it on a LARGE file. )
Well - I *did* note that it was not_ready_for_prime_time !
I'll post a better version when it's finished ( along with
the readuntil( 'string' ) or readuntil( regexp ) additions.
Please excuse me for posting alpha code - I just want to
keep the discussion moving with some examples.