The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

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