import bzrlib.lru_cache

You should probably start looking in bzrlib for your coding needs

-Rob

Robert, you're almost certainly right that it might be worthwhile invest time and energy learning bzrlib so I could benefit from all the great work the bzr developers have done. It is not very high on my list of things to do, however.

bzrlib is a huge big dependency that I do not want to inflict on people. Also, it's big enough that it'd take a long time to get familiar with it, and to keep track of it every month when it changes. And to backport it to the Debian stable release or wherever. All of which is not the kind of fun I want to have while programming in my free time. (Productivity being less important than fun in my free time.)

I'm not saying it wouldn't be worthwhile, but, on the whole, the benefits have to be clear and immediate for me to overcome my NIH.

In this particular case, I did a couple of quick speed tests. Both implementations are very close to the same speed. Mine is slightly slower, on the order of 20%, using a modified version of speed-test in my source tree. With max 100 elements, 18.5 versus 15.6 milliseconds per loop, according to timeit. With 10,000 elements, 13.1 versus 11.1 milliseconds.

Not bad for an evening's work, if I say so myself.

Do you think it might be possible for bzrlib to be broken down into smaller, more easily grokked libraries?

Writing good reusable code is hard. Getting people to use it is harder.