question of style

[Steven D'Aprano]

On Fri, 03 Jul 2009 13:50:12 -0700, Paul Rubin wrote:

> I wouldn't say Python's None is terrible, but the programming style in
> which None is used as a marker for "absent value" is genuinely a source
> of bugs, requiring care when used.  Often it's easy to just avoid it and
> all the bugs that come with it.

So you keep saying, but I don't believe it. I've never found this to be a 
problem in my own code: a few silly mistakes where I accidentally assign 
the result of a function that operates by side-effect:

blist = alist.sort()

or similar, and I haven't done that for years now.

No, wait, I tell I lie... re.search() sometimes bites me, because 
sometimes it returns None and sometimes it returns a matchobject and I 
don't use re often enough to have good habits with it yet. But that's a 
good example of why removing NULL (None, nul, nil, whatever you want to 
call it) doesn't lower the number of bugs, it just changes their nature: 
if re.search didn't return None, I'd still have trouble with it.

There are three natural approaches to (say) re.search() for dealing with 
failure:

(1) return a sentinel value like None;

(2) return a matchobject which tests False;

(3) raise an exception.

Here's how you would use them correctly:


# 1 or 2 are handled identically
o = re.search(s)
if o:
    process_match(o)
else:
    print "Not found"


# 3 is different
try:
    process_match(re.search(s))
except Exception:
    print "Not found"


There's essentially little or no difference in the handling. In all three 
cases, if you assume search will always succeed or forget to handle the 
failure case, you will write incorrect code:

process_match(re.search(s))

and get an unexpected exception. The only difference is that the specific 
exception will differ between the cases. Remove None from the scenario 
doesn't reduce the number of bugs, it just changes their nature.



-- 
Steven