The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
BartC
bc at freeuk.com
Tue Mar 22 10:02:25 EDT 2016
On 22/03/2016 13:13, Chris Angelico wrote:
> On Tue, Mar 22, 2016 at 11:59 PM, BartC <bc at freeuk.com> wrote:
> The first step in any program is to write it in the very simplest way
> possible. That usually means ignoring all error handling. And yes,
> this is true in EVERY language - C, PHP, Pike, DeScribe Macro
> Language, you name it. Then you try it, and you find one of two
> things:
(Not in C; you can cause serious damage! But when I tried that approach
in my experimental Python programs, it wasn't popular, I recall.)
> Note, though, that "deal with" really means "deal with", and NOT
> "print oops to the console and terminate". If all you're going to do
> with an exception is print and terminate, *let it go*, unless it's a
> user-triggered failure, in which case you catch it right at the very
> highest level, and basically fall off the end of your program. The
> number of times you have sys.exit() in an except clause should be
> vanishingly small.
So code like the following is consigned to history?
while 1:
| file = input ("Filename (press enter to quit)? ")
| if file == "": break
| print ("Trying to open:",file,"...")
| s = readstrfile(file)
| if s != 0:
| | print (" ",file,"has",len(s),"characters")
| else:
| | print (" There was a problem opening:",file)
(Oops, ignore the bars.)
And, forgetting file input for a minute, what about function return
values in general; should they still be allowed to return some status or
error codes, or does it all have to be exceptions now?
I mean, is a function allowed to still return True or False, or just
False? (Or perhaps just nothing if the exception mechanism can signal
either.)
--
Bartc
More information about the Python-list
mailing list