I agree, that was the topic of my original post to the python-ideas discussion group[1]. I thought we should special-case `lru_cache()` to account for this use case.
The general consensus was that a `once()` decorator would be less confusing and more semantically correct than using `lru_cache` like this. I can also see the reasoning behind that point of view, and it could be further argued that using `lru_cache()` in a non-lru way might be more confusing.
I read the discussion, what I saw was this:
Eiffel uses the keyword “ONCE” for this. I would prefer a similar
approach, using a specialised decorator, rather than to special-case
lru_cache
- Steven D'Aprano
Steven, can you elaborate why you prefer this?
Semantically, is this a special case? It seems to follow very naturally from the definition of lru_cache. Is it more special than sum([]), any([]), or all([])?
Agreed, a special @once decorator sounds like a better approach here.
and later:
but don’t try to make [lru_cache] the “sanctioned” way to do call-once functions. If it’s to be “official”, it should be more discoverable/obvious (i.e., a @once decorator), rather than a side-effect of adding a LRU cache.
- Paul Moore
Again, is this a side effect, or the natural expected result?
Adding bloat to the API and documentation seems like it will reduce the discoverability of the language overall.
Was there anything else in that thread?
Do two people make a consensus? Do others agree with this approach?
Is there any precedent for something like this in Python? A function which acts just like another function, but only accepts a subset of the arguments?
People are going to use lru_cache for this use case regardless of this proposal. A lot of existing code using it is not going to change. Libraries wanting to support 3.8 and below will use it. Many people will never learn about @once. Why not fast-path lru_cache for zero arguments anyway?