[EMAIL PROTECTED] wrote: > On Sep 6, 12:41 pm, Tim Golden <[EMAIL PROTECTED]> wrote: >>> Thanks! I'll try it both ways and see if there's any appreciable >>> difference in speed, although since it will be packaged into an >>> executable, that may not be an issue anyway. >>> Mike >> I honestly doubt there's any advantage to my approach, certainly >> not in terms of speed. It's really only if it happens to suit >> your mind better, or take advantage of structures you might >> already have in place, etc. >> >> TJG > > For completeness, here's my method for comparison's sake: > [... snipped ...]
> Isn't it kind of late in the day over there, Tim? (It's about 8.30pm as I write this, so still awake :) > Anyway, your method is probably clearer to read whereas mine > doesn't require anything to be imported. I think I've been a SQL & Python programmer for so long that I tend to do anything -- and sometimes too much -- to avoid messy loop/exit-when structures. On reflection, my code would be simplified by ignoring all the datetime.date stuff which is irrelevant for the purpose, since tuples will compare perfectly well. Also, I had to put the conditional in the loop because I didn't have data for every month. If you *knew* you had at least one period for each month and weren't fussed about, say, date arithmetic later on, it would be even simpler, just a min () function around a generator expression. Frankly, though, with code as small scale as this, it's far more important what *you* the programmer and any future maintainers will find easy to understand and use, and far less important how clever the code is or how fast it runs. > I didn't even realize there was a calendar module...or > maybe I forgot about it. Even now, after some seven years of using Python, I'm *still* surprised when I read someone's blog article or mailing list posting referring to a module or application I never knew about, or had completely forgotten. TJG -- http://mail.python.org/mailman/listinfo/python-list