# [Tutor] am I missing another simpler structure?

Brian van den Broek bvande at po-box.mcgill.ca
Thu Dec 16 07:06:58 CET 2004

```[Brian van den Broek]

<SNIP setup of how I was wondering if I was making things too
complicated with:>

>>import datetime
>>def is_leap_year(year):
>>    '''-> boolean
>>
>>    Returns True or False as year is, or is not, a leap year.
>>    '''
>>    is_leap = True
>>    try:
>>        datetime.date(year, 2, 29)
>>    except ValueError:
>>        is_leap = False
>>    return is_leap

Kent Johnson said unto the world upon 2004-12-15 20:16:
> I would write
> def is_leap_year(year):
>     try:
>         datetime.date(year, 2, 29)
>         return True
>     except ValueError:
>         return False

Not an adherent of the "only one exit point" doctrine then, hey? I spent
a while a few weeks ago with a bug in a function that happened because
I'd not noticed that I had two return statements, so I'm leery of this
at the moment. (I concede if the function was long enough to hide that
from me, it was probably too long.) I also like the conceptual purity of
one way in and one way out. But, in my code above, that is indeed
purchased at the cost of the ugly and a bit anomalous assignment of True.

Tim Peters said unto the world upon 2004-12-15 23:14:

> So far as leap years go, the obvious difference is that February has
> 29 days in leap years, but only 28 otherwise.  You exploit that above
> by checking whether trying to construct "February 29th" raises an
> exception.  That's fine.  At least an equally good way is to note that
> the difference between March 1 and Februrary 28 is 2 days only in a
> leap year, so:
>
> from datetime import date, timedelta
> def isleap(year):
>     return (date(3, 1, year) - date(2, 28, year)).days == 2

<SNIP 2 other ways of similar style>

> def isleap(year):
>     return (date(year+1, 1, 1) - date(year, 1, 1)).days == 366
>
> IOW, if you can think of one way to do it with a Boolean expression,
> it's common to think of more.  And, of course, that's the kind of
> practice that makes it feel natural, over time.

4 ways all shorter than mine; well, thank goodness I wasn't asking about
this in Perl ;-)

Thanks for the examples. Pretty and concise often go together, but they
seem not to be want to be seen with me. Implausible though my posting
history may make it sound, I've done a fair bit of work in set theory
and math. logic. While my proofs work, they are almost never pretty or
concise. Seems like my code has similar tendencies. I appreciate the
pushes in a better direction.

At least I won't be stuck for things to do when it comes time to refactor!

Thanks to both,

Brian vdB
```