On Sun, Apr 26, 2020 at 7:47 PM Eric Fahlgren <ericfahlgren@gmail.com> wrote:
On Sun, Apr 26, 2020 at 9:46 AM Alex Hall <alex.mojaki@gmail.com> wrote:
It's not clear to me why people prefer an extra function which would be exactly equivalent to lru_cache in the expected use case (i.e. decorating a function without arguments). It seems like a good way to cause confusion, especially for beginners. Based on the Zen, there should be one obvious way to do it.
I don't believe it is. lru_cache only guarantees that you will get the same result back for identical arguments, not that the function will only be called once. Seems to me if you call it, then in the middle of caching the value, there's a thread change, you could get to the function wrapped by lru_cache twice (or more times).
Is that desired behaviour? Maybe we should consider changing it, at least for the zero-argument case?
In order to implement once, it needs to contain a thread lock to ensure its "once" moniker and support the singleton pattern for which it is currently being used (apparently incorrectly) in django and other places. Am I understanding threading correctly here?
Should we require everyone else to fix their broken code if we can fix it ourselves? If once() has a thread lock and lru_cache doesn't, I imagine once() might be slower in the single threaded case. Can this be checked? Do we want to leave users deciding between performance and thread safety?