I find multiple returns to be rather useful - def isOdd(x):
if not x % 2: return False return True On Thu, 16 Dec 2004 01:06:58 -0500, Brian van den Broek <[EMAIL PROTECTED]> wrote: > [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 > _______________________________________________ > Tutor maillist - [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/tutor > -- 'There is only one basic human right, and that is to do as you damn well please. And with it comes the only basic human duty, to take the consequences. _______________________________________________ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
