The example is terrible. It's understandable that OP wants to keep it as short as possible. But it is made so simple that it fails to convey the point. You woul

The example is terrible. It's understandable that OP wants to keep it as short as possible. But it is made so simple that it fails to convey the point. You would obviously not want to use the DeadlineSetter class here. It doesn't even ever access its "entity_type" field. All code bases I have seen in the past 15 years have too little DRY, not too much. Yes, every technique we use has pros and cons and we need to decide in each case whether DRY is worth it. But I worry that people will come away from the article (or even just the headline) with the feeling that "ah, I don't need to DRY". I've been in the situation too many times where somebody copy-pasted and I later had to make it DRY to achieve consistent behavior. Let's err on the side of DRY. In the example, the right-hand side could either be left as-is. Or it could extract a function: def set_task_deadline(task_deadline): _ensure_is_in_future(task_deadline) def set_payment_deadline(payment_deadline): _ensure_is_in_future(payment_deadline) def _ensure_is_in_future(deadline): if deadline <= datetime.now(): raise ValueError(“Date must be in the future”) This is much better than the straw man example employed by the author.