Simon Forman <sajmik...@gmail.com> writes: > "...stick to the principle: NULL is wrong because it causes horrible > and tricky mistakes which appear even after the program was tested > thoroughly. You cannot introduce NULL into the language and tell the > programmer to be careful about it. The programmer is not capable of > being careful!" > > To me that seems weak and too general, you could say /anything/ > "...causes horrible and tricky mistakes which appear even after the > program was tested thoroughly."
On the contrary, general means powerful :). For example, you can say that malloc/free in C causes horrible and tricky mistakes etc. Python avoids the mistakes by having automatic storage management. > Which I agree with wholeheartedly. I just don't see that he made a > strong case that the inclusion of NULLs directly implies poor quality > of language. > > (I like Haskell's Maybe, but saying A is better than B doesn't imply > that B is therefore terrible.) 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. Haskell's Maybe type, ML's Option type, and various similar constructs in other recently designed languages all are responses to the shortcomings of None-like constructs in older languages. I'm not going purely by that one guy's blog post, though I do think that post was pretty good. > Hmm, I really don't see that using an empty list rather than None as a > stand-in for NULL pointer bought you anything there. In fact, this > code would work identically if you replaced [] with None. Yes I noticed that too (and mentioned it) after writing the code. I think the real problem is that the class has unnatural semantics and Python's OOP system (well, OOP in general) is also sort of kludgy. I will think about a possible rewrite. -- http://mail.python.org/mailman/listinfo/python-list
