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/cecf049673da6a24435acd1a6a3b34472b323c97/Lib/functools.py#L763
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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/J6G33EDWEH6ZAFW4BRH2EBYG77DNX6OI/
Code of Conduct: http://python.org/psf/codeofconduct/
