What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Wed, 10 Aug 2016 04:29 am, Juan Pablo Romero Méndez wrote:

> Hello,
> 
> In online forums sometimes people complain that they end up having to test
> constantly for None, 

Then don't return None to indicate an error. If you write this:

def create_spam(arg):
    if condition:
        return Spam(arg)
    else:
        return None


then you are doing it wrong. It sounds like they are writing C in Python,
where they think that returning None (instead of a null pointer) is the way
to indicate an error. Instead:

def create_spam(arg):
    if condition:
        return Spam(arg)
    raise MyExceptionError('cannot create spam because reasons')


Now you can decide on a error-handling scheme:

- try...except and handle the exception exactly when it occurs;

- wrap your entire application in a single try...except or 
  exception handler, and catch the exception in a single place;

- don't even bother catching the exception in the application at all, 
  treat it as a debugging aid. Any time your tests generate that 
  exception, that's a bug to be fixed.


There's no reason why you can't decide on a combination of all three:

- the app catches the exception, logs it as a bug, and exits;

- but individual parts of your code base treat this exception as an 
  EXPECTED error, wrapping that individual call in a try...except:


    try:
        myspam = create_spam(99)
    except MyExceptionError:
        # Only occurs when the server has hung
        reboot_server()
        myspam = create_spam(99)


Only catch exceptions you expect, and can recover from.

If your *data* could be None, well that's no different from any other
sentinel or missing value. You have to deal with it somewhere. One way is
to filter it early:

# filter out None
data = [obj for obj in data if data is not None]

# or if you prefer
data = filter(lambda obj: obj is not None, data)


and now you can be sure that data doesn't contain None.


[...]
> Do you guys have any resources you like that addresses the following
> issue: What is the best way to use the dynamic features of Python to avoid
> having to write a poor's man type system?

This is an old, old, old debate that applies to Lisp, Perl, Javascript, Lua,
Ruby and others, not just Python. Google for "dynamic typing versus static
typing" for more. Also google for "duck typing".

One useful perspective is that languages are converging on a mix of both:
statically typed languages are growing dynamic features, and dynamically
typed languages are growing static checkers.


http://steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html


And some background information on the debate:

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.