Thomas Kemmer

@vit-zikmund: Finally found the time to give that a closer look, so AFAICS this is rather similar to https://github.com/tkem/cachetools/pull/224, i.e. there might be a rather large number of ``(R)Lock``s (or...

I totally agree with you ;-) However, my time is limited, and IMHO this shouldn't be part of CI due to limited reliability regarding to timing of CI frameworks/machines. But...

There's a branch, incorporating some gists that I found useful. However, I do _not_ want to make this something "official", that I have to support. So closing this for good's...

Sorry, but as stated [elsewhere](https://github.com/tkem/mopidy-mobile/issues/251), Mopidy-Mobile is mostly based on outdated, deprecated and no longer supported technology. This is even more the case regarding the Android app. I was already...

Hmmm... Didn't care to much, since these are only build/test dependencies, `cachetools` by itself shouldn't have any deps apart from the standard Python libs. But I'll read up on that...

Giving `cachetools`' 10+ year history, someone should have a look if building and distribution are still "state of the art", or if there should be some improvements. Including handling of...

Good point, and thanks for sharing! It's an issue with the way decorators handle their arguments, which also affects the Standard Library's [functools.lru_cache](https://docs.python.org/3/library/functools.html#functools.lru_cache) implementation, that I, quite frankly, haven't been...

This might also be relevant to Mopidy-dLeyna to retrieve only compatible resources from transcoding DLNA media servers.