part 1 part 2 part 3 part 4 part 5 part 6

Last time... Last time we've discussed guard clauses and when not to use them. We've discussed the paranoia developers sometimes feel that causes them to write useless or even harmful guard clauses. The best way to reduce paranoia about None is to make sure it can't be there in the first place. So let's talk about ways to accomplish this.

Edge case This handwaves the edge case where start_date and end_date are both equal to INDEFINITE_PAST or INDEFINITE_FUTURE , which can be argued should not raise ValidationError . In software for a time machine it might be important to get this right, but in many applications not handling this edge case is fine.

Really avoiding the edge cases If we insist on making the edge case go away, we could deal with it by subclassing the date class to construct these sentinels instead: class IndefinitePast(date): def __lt__(self, other): return True def __le__(self, other): return True def __gt__(self, other): return False def __ge__(self, other): return False class IndefiniteFuture(date): def __lt__(self, other): return False def __le__(self, other): return False def __gt__(self, other): return True def __ge__(self, other): return True INDEFINITE_PAST = IndefinitePast(datetime.MINYEAR, 1, 1) INDEFINITE_FUTURE = IndefiniteFuture(datetime.MAXYEAR, 12, 31) This is a lot more code though, and therefore in many situations this would be overkill. (As a puzzle for the reader in this case one could safely skip implementing __le__ and __ge__ for these classes and still have it all work for any possible date. I kept them in for clarity.)

Normalization So what have we done here? We've made sure that our input was normalized to a date before it even reached the validation function. This way we don't have to worry about our friend None when we deal with dates. The idea is to normalize the input a soon as possible before it reaches the rest of our codebase, so we can stop worrying about non-normalized cases (such as None ) everywhere else. In effect you put the guard clauses as far on the outside of the calling chain as possible. In the case of our date input, somewhere in the input processing we'd call these functions: def process_start_date(d): if d is None: return INDEFINITE_PAST return d def process_end_date(d): if d is None: return INDEFINITE_FUTURE return d None of those None 's to worry about anymore after that!

Drawbacks Normalization also has some potential drawbacks. Here are some that may apply to this case: to understand how empty date fields are treated in the validation function, we need to read normalization code that may be somewhere else. Our validation function that worried about None was all in one place.

it's more code to understand and maintain, especially with the custom date subclasses.

normalization of None to a date may be nice during validation, but it may not be what we want to store in a database; we might want to store None there. If we have this requirement we'd need two code paths: one for storage and one for validation. It all depends on the exact details of your project. If the project is going to compare a lot of dates in many places, it makes sense to normalize missing values to proper dates as soon as possible, and it's a much better approach than having to worry about None everywhere. But if the project only needs a single validation rule that can handle missing dates, then it makes more sense to write one that deals with None directly.