[issue36772] Let lru_cache be used as a decorator with no arguments

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue36772] Let lru_cache be used as a decorator with no arguments

Raymond Hettinger added the comment: New changeset b821868e6d909f4805499db519ebc2cdc01cf611 by Raymond Hettinger in branch 'master': bpo-36772 Allow lru_cache to be used as decorator without making a function call (GH-13048) https://github.com/python/cpython/commit/b821868e6d909f4805499db519

[issue36772] Let lru_cache be used as a decorator with no arguments

Pablo Galindo Salgado added the comment: I am +1 to this. Making it easier for the case of decorator factories that are called with all the defaults is a very common pattern in the wild. There are even known idioms for how to reduce the indentation of the naive approach (returning partials o

[issue36772] Let lru_cache be used as a decorator with no arguments

Serhiy Storchaka added the comment: To clarify, I am not opposing this feature. I had doubts because if the memory does not betray me similar propositions for lru_cache or other decorator fabrics were rejected in past. But times change. -- ___ Pyt

[issue36772] Let lru_cache be used as a decorator with no arguments

Eric Snow added the comment: As to the issue of positional vs. keyword arguments, keyword arguments make the implementation easier in some cases. Otherwise I haven't seen positional arguments cause much of a problem. -- ___ Python tracker

[issue36772] Let lru_cache be used as a decorator with no arguments

Eric Snow added the comment: FWIW, I've followed this pattern (one function is both decorator and factory) in my own code for quite a while. I've never found it confusing nor has anyone else (that I'm aware) that has used those decorators. One reason I've done decorators this way is because

[issue36772] Let lru_cache be used as a decorator with no arguments

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue36772] Let lru_cache be used as a decorator with no arguments

Raymond Hettinger added the comment: At Pycon today, I mostly got all positive feedback on this. Apparently py.test already follows this pattern. Another developer said they found the () to be distracting and would welcome not having to use them. -- ___

[issue36772] Let lru_cache be used as a decorator with no arguments

Change by Raymond Hettinger : -- nosy: +dino.viehland, eric.snow, giampaolo.rodola, njs ___ Python tracker ___ ___ Python-bugs-list

[issue36772] Let lru_cache be used as a decorator with no arguments

Stefan Behnel added the comment: I'm generally ok with such APIs. It seems needless to require @lru_cache() def f(): ... when a simple decorator would suffice. I think I might decide otherwise in cases where almost all usages require arguments, but if the no-arguments case is common (an

[issue36772] Let lru_cache be used as a decorator with no arguments

Eric V. Smith added the comment: The 90% use case with dataclasses is satisfied with just "@dataclass", and perhaps the target user there is less sophisticated. But the main difference between @dataclass and @lru_cache is that all of the parameters to @dataclass are keyword-only. Which I did

[issue36772] Let lru_cache be used as a decorator with no arguments

Serhiy Storchaka added the comment: I do not like mixing decorators and decorator fabrics. But this can of worms has already been open by dataclasses. The question is whether we want to extend this design to the rest of the stdlib. lru_cache() resisted this change for a long time. -

[issue36772] Let lru_cache be used as a decorator with no arguments

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +12967 stage: -> patch review ___ Python tracker ___ ___ Python-bu

[issue36772] Let lru_cache be used as a decorator with no arguments

New submission from Raymond Hettinger : Follow the lead of the dataclasses module and allow lru_cache() to be used as a straight decorator rather than as a function that returns a decorator. Both of these would now be supported: @lru_cache def f(x): ... @lru_cache(maxsiz