None versus MISSING sentinel -- request for design feedback

[Steven D'Aprano]

Cameron Simpson wrote:

> 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? 

Maybe, maybe not. Either way, it has nothing to do with me -- I only care
about what my library does if presented with None in a list of numbers.
Should I treat it as a missing value, and ignore it, or treat it as an
error?


> 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:
[code snipped]

Yes, that's the main example I can think of. It doesn't really matter how it
happens though, only that it is more likely for None to accidentally get
inserted into a list than it is for a module-specific MISSING value.

My thoughts are, if my library gets presented with two lists:

[1, 2, 3, None, 5, 6]

[1, 2, 3, mylibrary.MISSING, 5, 6]

which is less likely to be an accident rather than deliberate? That's the
one I should accept as the missing value. Does anyone think that's the
wrong choice?


> I suppose there's no scope for having the append-to-the-list step sanity
> check for the sentinel (be it None or otherwise)?

It is not my responsibility to validate data during construction, only to do
the right thing when given that data. The right thing being, raise an
exception if values are not numeric, unless an explicit "missing" value
(whatever that ends up being).


> | 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?

Assuming I choose against None, and go with MISSING, it will be a public
part of the library API. The idea being that callers will be responsible
for ensuring that if they have data with missing values, they insert the
correct sentinel, rather than whatever random non-numeric value they
started off with.



-- 
Steven