It's convenient to use @lru_cache on functions with no arguments to delay doing some work until the first time it is needed. Since @lru_cache is implemented in C, it is already faster than manually caching in a closure variable. However, it can be made even faster and more memory efficient by not using the dict at all and caching just the one result that the function returns.

Here are my timing results. Before my changes:

$ ./python -m timeit -s "import functools; f = functools.lru_cache()(lambda: 1)" "f()"
5000000 loops, best of 5: 42.2 nsec per loop
$ ./python -m timeit -s "import functools; f = functools.lru_cache(None)(lambda: 1)" "f()"
5000000 loops, best of 5: 38.9 nsec per loop

After my changes:

$ ./python -m timeit -s "import functools; f = functools.lru_cache()(lambda: 1)" "f()"
10000000 loops, best of 5: 22.6 nsec per loop

So we get improvement of about 80% compared to the default maxsize and about 70% compared to maxsize=None.

Just use the new @cache decorator.¹  It's cleaner looking in code and already sets maxsize to None, making it perfect for your application.

With respect to the proposed optimization, I'm sorry but further optimization of this already fast special case isn't worth the added complexity.  It is almost certain that these few nanoseconds won't ever matter in a real application.  The @cache decorator is already faster than calling an empty function, "def f(): return None".

¹ https://docs.python.org/3/library/functools.html#functools.cache

As you can see in my original post, the difference between @cache (aka @lru_cache(None)) and just @lru_cache() is negligible in this case. The optimization in this PR makes a much bigger difference. At the expense of some lines of code, that's true.

Also, function calls in Python are quite slow, so being faster than a function call is not a high bar.

Some other thoughts:

* A zero argument function that returns a constant is unlikely to ever be used in a tight loop. That would be pointless.

* The @cache decorator is already 30% faster than calling an empty function. It's very cheap.

* We really don't want the cache logic to get into the business of trying to deduce the arity of the function being cached.  That is a can of worms that we would regret opening.

Additional discussion on the same topic on discourse: https://discuss.python.org/t/reduce-the-overhead-of-functools-lru-cache-for-functions-with-no-parameters/3956

Ammar, thank you for the link.

FYI: The @cache decorator was added as a result of that discussion and the related on python-ideas.

@cache does not address the problem or any of the concerns brought up in the thread. Thread-safe @once is a nice idea, but more work of course.