Finding specific date ranges

[Tim Golden]

kyosohma at gmail.com wrote:
> On Sep 6, 12:41 pm, Tim Golden <t... at timgolden.me.uk> 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