None versus MISSING sentinel -- request for design feedback
cs at zip.com.au
Fri Jul 15 09:44:03 CEST 2011
On 15Jul2011 15:28, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
| In favour of None: it's already there, no extra code required. People may
| expect it to work.
Broadly, I like this one for the reasons you cite.
| Against None: it's too easy to mistakenly add None to a data set by mistake,
| because functions return None by default.
This is a hazard everywhere, but won't such a circumstance normally
break lots of stuff anyway? What's an example scenario for getting None
by accident but still a bunch of non-None values? The main one I can
imagine is a function with a return path that accidentally misses the
value something, eg:
I suppose there's no scope for having the append-to-the-list step sanity
check for the sentinel (be it None or otherwise)?
| In favour of a dedicated MISSING singleton: it's obvious from context. It's
| not a lot of work to implement compared to using None. Hard to accidentally
| include it by mistake. If None does creep into the data by accident, you
| get a nice explicit exception.
I confess to being about to discard None as a sentinel in a bit of my
own code, but only to allow None to be used as a valid value, using the
def __init__(self, ...):
self._sentinel = object()
| Against MISSING: users may expect to be able to choose their own sentinel by
| assigning to MISSING. I don't want to support that.
Well, we don't have readonly values to play with :-(
Personally I'd do what I did above: give it a "private" name like
_MISSING so that people should expect to have inside (and unsupported,
unguarenteed) knowledge if they fiddle with it. Or are you publishing
the sentinal's name to your callers i.e. may they really return _MISSING
legitimately from their functions?
Cameron Simpson <cs at zip.com.au> DoD#743
What's fair got to do with it? It's going to happen. - Lawrence of Arabia
More information about the Python-list