On 22.09.2015 05:15, Steven D'Aprano wrote:
On Mon, Sep 21, 2015 at 05:23:42PM -0400, Terry Reedy wrote:
I agree with Paul Moore that propagating None is generally a bad idea.
As I understand it, you and Paul are describing a basic, simple idiom which is ubiquitous across Python code: using None to stand in for "no such value"
There is not a single "no such value". As I mentioned before, when discussing NULL values on the RDF mailing list, we discovered 6 or 7 domain-agnostic meanings.
when the data type normally used doesn't otherwise have something suitable. Consequently I really don't understand what you and Paul have against it.
I can tell from what I've seen that people use None for: all kinds of various interesting semantics depending on the variable, on the supposed type and on the function such as:
- +infinity for datetimes but only if it signifies the end of a timespan - current datetime - mixing both - default item in a list like [1, 2, None, 4, 9] (putting in 5 would have done the trick) - ...
Just imagine a world where Python and other systems would have never invented None, NULLs or anything like that.
I think you meant to say it merely *postpones* the inevitable exception. But that's wrong, there's nothing inevitable about an exception here. It's not *hard* to deal with "value-or-None". It's just tedious, which is why a bit of syntactic sugar may appeal.
It's a sign of bad design. So, syntactic sugar does not help when doing toilet paper programming (hope that translation works for English).