Menu
Like you said, return None is (almost) never needed. But you should consider that the intention of your code is much clearer with an explicit return None . Remember: a piece of code also needs to be readable by human-beings, and being explicit usually helps. "Explicit is better than implicit."
It's generally bad form to return None meaning "everything is fine." If you have some kind of lookup/accessor, None means "the value of that item is None", and when it's not found you should throw the appropriate exception.
If your function performs actions but doesn't have a clear and useful return value, then you can omit returning None because doing that would just be superfluous and confusing. You can also use a bare return without a return value just to make clear your intention of returning from the function.
This will also return None , but that value is not meant to be used or caught. It simply means that the function ended successfully. It's basically the same as return in void functions in languages such as C++ or Java.
I would return None. If there is no result, why return something that looks like a result?
It is also easier to test:
result = getCity()
if result:
# do something
I would only return (None, None) if it were possible that only one of the two values is None (i.e. ('Boston', None)). It would be more consistent in this case.
By only returning one value in exceptional circumstances, you risk breaking the tuple unpacking idiom. Some of your callers might issue:
city, state = getCityStateTuple("something")
In that case, returning None will break the caller with the error:
TypeError: 'NoneType' object is not iterable
So, I personally would return (None, None) in your situation. Then again, your mileage may vary, and it depends on the pattern used by your callers.
(None, None) does not evaluate to False in Python. In addition, building a tuple requires more work than, well, not building a tuple. So I would prefer None.
As others have noted, a tuple with items in it does not test as False, which is one reason you might want to return None rather than (None, None). However, it is possible to write a tuple subclass that tests as False even when it has items in it by overriding its __nonzero__() method.
class falsetuple(tuple):
def __nonzero__(self):
return False
Then you could return falsetuple((None, None)) when there is no value available. In fact, you could always return the same falsetuple.
I'm not necessarily recommending that you do this, in fact I have serious misgivings about flouting this convention, I'm just saying that the truthiness of non-empty tuples is not necessarily in itself a reason to not return a tuple.
If your routine normally returns a tuple, then a tuple is what it should keep returning. The real choice is between returning (None, None), or raising an exception, and we don't have enough information to offer good advice on that.
If it were me, and I chose the tuple over the exception, I would go with the FalseTuple that kindall suggests, and also realize that the calling code (which is using tuple unpacking) can also test
if city is None:
to see if a valid result was obtained. This way you are supporting tuple extraction across all possible return values, and still allowing the pythonic idiom of asking the object, "Do you evaluate as True?" (Here is kindall's again for completeness):
class FalseTuple(tuple):
def __nonzero__(self):
return False
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With