On 28Apr2020 1243, Petr Viktorin wrote:
On 2020-04-28 00:26, Steve Dower wrote:
On 27Apr2020 2311, Tom Forbes wrote:
Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration time and return a different object.
It’s not that it’s impossible, but I didn’t think the current implementation doesn’t make it easy
This is the line I'd change: https://github.com/python/cpython/blob/cecf049673da6a24435acd1a6a3b34472b323...
At this point, you could inspect the user_function object and choose a different wrapper than _lru_cache_wrapper if it takes zero arguments. Though you'd likely still end up with a lot of the code being replicated.
Making a stdlib function completely change behavior based on a function signature feels a bit too magic to me. I know lots of libraries do this, but I always thought of it as a cool little hack, good for debugging and APIs that lean toward being simple to use rather than robust. The explicit `call_once` feels more like API that needs to be supported for decades.
I've been trying to clarify whether call_once is intended to be the functional equivalent of lru_cache (without the stats-only mode). If that's not the behaviour, then I agree, magically switching to it is no good. But if it's meant to be the same but just more efficient, then we already do that kind of thing all over the place (free lists, strings, empty tuple singleton, etc.). And I'd argue that it's our responsibility to select the best implementation automatically, as it saves libraries from having to pull the same tricks. Cheers, Steve