On Sun, Apr 26, 2020 at 7:47 PM Eric Fahlgren <ericfahlg...@gmail.com> wrote:
> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall <alex.moj...@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?
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/24D3SSBUOSR3RIGHGW2IDT52RFG7AR3B/ Code of Conduct: http://python.org/psf/codeofconduct/
