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.
You're probably right to go for the C implementation. If the Python implementation is correct, then best to leave the inefficiencies there and improve the already-fast version.
Looking at https://github.com/python/cpython/blob/master/Modules/_functoolsmodule.c it seems the fast path for no arguments could be slightly improved, but it doesn't look like it'd be much. (I'm deliberately not saying how I'd improve it in case you want to do it anyway as a learning exercise, and because I could be wrong :) )
Equally hard to say how much more efficient a new API would be, so unless it's written already and you have benchmarks, that's probably not the line of reasoning to use. An argument that people regularly get this wrong and can't easily get it right with what's already there is most compelling - see the recent removeprefix/removesuffix discussions if you haven't.
Cheers, Steve