On Sep 6, 2:39 pm, Tim Golden <[EMAIL PROTECTED]> wrote: > > > 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. >
I'm getting pretty sick of for loops, flags and/or sentinel values. I do *know* that there should be one (and only one) period per month that applies. I just have to grab that period. I currently calculate the date ranges on the fly based on the last date in the 2-value pair. Ugh. I've read an re-read about generators, but they seem to cause my mind to go blank. It's like the related with statement or decorators. I just don't understand them well enough to implement them. > 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 agree. The simpler the code is to read and maintain, the better. Clever, short code may be cool, but it can also be a pain to troubleshoot. Mike -- http://mail.python.org/mailman/listinfo/python-list
