On Fri, 20 Feb 2015 07:11:13 +1100, Chris Angelico wrote: > On Fri, Feb 20, 2015 at 7:03 AM, Denis McMahon <denismfmcma...@gmail.com> > wrote: >> On the one hand, the return type of a function (when it returns, >> rather than raising an exception) should be consistent to itself, >> even if using a language where types are not declared. > > Yes, so I'd advise against having a function sometimes return a string > and sometimes a dict. Sure. But None gets a bit of a special pass > here; in a lot of languages, what you'd have is a "nullable" type (eg > in C you might declare the return value as "pointer to char", and > either return a pointer to a string, or NULL), but in Python, you > return None for the special case. So in a sense, "str or None" is not > so inconsistent.
I'm an old C and assembly language programmer, but the older I get, the less I use null (in C or in Java), None (in Python), or equivalent in other languages. If a function can't perform its side effect (like renaming a file), then raise an exception. If a function called for its value can't return that value, then raise an exception; if there are no values to return, then return an empty collection. How much code do we write and read that checks for null (or None, or whatever), and how much time do we spend writing it and reading it? Readability counts. Simple is better than complex. Explicit is better than implicit. Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. (Wow! I knew I could turn to the Zen for support, but I didn't realize just how much support I would get!) See also <http://en.wikipedia.org/wiki/Void_safety>. Dan -- https://mail.python.org/mailman/listinfo/python-list
