Ok, thank you. I will make the issue and pull request once the switch to GitHub
issues is done.
On Sun, Mar 6, 2022, at 10:20 AM, Eric V. Smith wrote:
>
>> On Mar 6, 2022, at 5:05 AM, Barry Scott wrote:
>>
>>
>>> On 6 Mar 2022, at 07:19, t...@tomforb.es wrote:
>>>
>>> For reference, this re
important especially when it’s more performant in the
general case. And clearly the current use of this pattern in the stdlib means
others have come to the same conclusion.
> On 2 May 2020, at 06:45, Andrew Barnert wrote:
>
> On May 1, 2020, at 09:51, Tom Forbes wrote:
>>
>&
Raymond Hettinger
> wrote:
>
>
>
>> On Apr 29, 2020, at 11:15 AM, Tom Forbes wrote:
>>
>> What exactly would the issue be with this:
>>
>> ```
>> import functools
>> from threading import Lock
>>
>> def once(func):
>&g
30 Apr 2020, at 03:09, Andrew Barnert wrote:
>
> On Apr 29, 2020, at 11:15, Tom Forbes <mailto:t...@tomforb.es>> wrote:
>>
>>> Thread 2 wakes up with the lock, calls the function, fills the cache, and
>>> releases the lock.
>>
>> What exact
re now slower.
Seems generally more correct, even in single threaded cases, to pay the
overhead only in the first call if you want `call_once` semantics. Which is why
you would be using `call_once` in the first place?
> On 29 Apr 2020, at 18:51, Andrew Barnert wrote:
>
> On Apr 29, 2020
What you want is to acquire a lock if the cache is empty, check if another
thread has filled the cache while you where waiting on the lock, call the
function, fill the cache and return.
I don’t see how you could implement that with two independent decorators
without locking all accesses (before
;>> before submitting a PR :-)
>>
>>
>> Is there a core developer with a particular interest in functools to be
>> consulted?
>>
>> -CHB
>>
>>
>>
>>
>>
>>>
>>>
>>> Regards
>>>
&g
I would think that would be a great name, it’s more explicit and fits more in
with its siblings “lru_cache” and “cached_property”.
Not to imply that there is a consensus to move forward, I would be interested
in knowing what the next steps would be if there was. Would this require a PEP
to be s
2020 at 1:54 PM Tom Forbes <mailto:t...@tomforb.es>> wrote:
> This is a good idea but some cases need to be lazily evaluated. Without that
> property `once()` loses a lot of utility. In the case of Django some of the
> decorated functions create objects that cannot be insta
;
> def once(func):
> return func()
>
> @once
> def pwd():
> return os.getcwd()
>
> print(pwd)
>
> On Sun, Apr 26, 2020 at 7:09 AM Tom Forbes <mailto:t...@tomforb.es>> wrote:
> Hello,
> I would like to suggest adding a simple “once” method to fun
which would be
> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
> function without arguments). It seems like a good way to cause confusion,
> especially for beginners. Based on the Zen, there should be one obvious way
> to do it.
>
> On Sun, Ap
Sun, Apr 26, 2020 at 03:03:16PM +0100, Tom Forbes
> wrote:
> > Hello,
> > I would like to suggest adding a simple ???once??? method to functools.
> As the name suggests, this would be a decorator that would call the
> decorated function, cache the result and return it wit
Hello,
I would like to suggest adding a simple “once” method to functools. As the name
suggests, this would be a decorator that would call the decorated function,
cache the result and return it with subsequent calls. My rationale for
suggesting this addition is twofold:
First: It’s fairly commo
13 matches
Mail list logo
