Cameron Simpson wrote: > On 15Jul2011 15:28, Steven D'Aprano <steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
