On Fri, 20 Feb 2015 02:08:49 +1100, Chris Angelico wrote: > On Fri, Feb 20, 2015 at 1:16 AM, Denis McMahon > <denismfmcma...@gmail.com> > wrote: >>> 2. no files match the given pattern >> >> Return either None, 0, False or an empty string. >> >> In both cases, it is then a matter for the calling code to catch the >> exception or handle the return value appropriately. > > I'd avoid the empty string here, because "absence of file" should be > very different from "first file matching pattern". Imagine this naive > code:
If your function documentation states that a failure to match any existing file returns an empty string (and if that's the case, then the documentation should do), then whoever calls the function should check the return value isn't an empty string. There's two conflicting "paradigms" as it were here. 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. On the other hand, a failure condition should clearly be a failure condition, which for a language that supports untyped functions means that we have the luxury of being able to return None / Nul[l] / NaN / False / 0 etc instead of a string / object / array / list / dictionary / mapping etc instead of raising an exception for the failure, and so we can try and handle the failure at the calling level without worrying about trapping exceptions. I guess at the end of the day the programmer has to consider and determine which is most appropriate to his application, given the case. As an aside, it's always a good idea to check that what you get looks like what you expected, whether it comes from a function call or as a data packet over the internet, before you start using it to do other things. ;) -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
