What behavior would you expect?
Denis McMahon
denismfmcmahon at gmail.com
Thu Feb 19 15:03:38 EST 2015
On Fri, 20 Feb 2015 02:08:49 +1100, Chris Angelico wrote:
> On Fri, Feb 20, 2015 at 1:16 AM, Denis McMahon
> <denismfmcmahon at 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, denismfmcmahon at gmail.com
More information about the Python-list
mailing list