01.05.20 01:23, Paul Ganssle пише:
class LazyList:
def __init__(self, some_iterator):
self._iter = some_iterator
self._list = None
@call_once
def as_list(self):
self._list = list(self._iter)
return self._list
call_once is not applicable here,
On 4/30/20 4:47 PM, raymond.hettin...@gmail.com wrote:
> Would either of the existing solutions work for you?
>
> class X:
> def __init__(self, name):
> self.name = name
>
> @cached_property
> def title(self):
> print("compute title once")
> return self.name.title()
On Thu, Apr 30, 2020 at 3:12 PM Raymond Hettinger
wrote:
> Thanks for the concrete example. AFAICT, it doesn't require (and probably
> shouldn't have) a lock to be held for the duration of the call. Would it be
> fair to say the 100% of your needs would be met if we just added this to the
> f
> On Apr 30, 2020, at 10:44 AM, Carl Meyer wrote:
>
> On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger
> wrote:
>> Do you have some concrete examples we could look at? I'm having trouble
>> visualizing any real use cases and none have been presented so far.
>
> This pattern occurs not in
Would either of the existing solutions work for you?
class X:
def __init__(self, name):
self.name = name
@cached_property
def title(self):
print("compute title once")
return self.name.title()
@property
@lru_cache
def upper(self):
print("compute u
> On Apr 30, 2020, at 6:32 AM, Joao S. O. Bueno wrote:
>
> Of course this is meant to be something simple - so there are no "real
> world use cases" that are "wow, it could not have
> been done without it".
The proposed implementation does something risky, it hold holds a non-reentrant
lock a
On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger
wrote:
> Do you have some concrete examples we could look at? I'm having trouble
> visualizing any real use cases and none have been presented so far.
This pattern occurs not infrequently in our Django server codebase at
Instagram. A typical ca
On Thu, 30 Apr 2020 at 00:37, Raymond Hettinger
wrote:
>
>
>
> > On Apr 29, 2020, at 4:20 PM, Antoine Pitrou wrote:
> >
> > On Wed, 29 Apr 2020 12:01:24 -0700
> > Raymond Hettinger wrote:
> >>
> Also, if you know of a real world use case, what solution is currently being
> used. I'm not sure w
On 30/04/20 3:29 pm, Raymond Hettinger wrote:
Do you think it is safe to hold a non-reentrant lock across an
arbitrary user function?
I think what's wanted here is to block if it's locked by
a different thread, but raise an exception if it's locked
by the same thread.
--
Greg
_
> On Apr 29, 2020, at 4:20 PM, Antoine Pitrou wrote:
>
> On Wed, 29 Apr 2020 12:01:24 -0700
> Raymond Hettinger wrote:
>>
>> The call_once() decorator would need different logic:
>>
>> 1) if the function has already been called and result is known, return the
>> prior result :-)
>> 2) if
On Wed, 29 Apr 2020 12:01:24 -0700
Raymond Hettinger wrote:
>
> The call_once() decorator would need different logic:
>
> 1) if the function has already been called and result is known, return the
> prior result :-)
> 2) if function has already been called, but the result is not yet known,
>
> On Apr 29, 2020, at 12:55 AM, Tom Forbes wrote:
>
> Hey Raymond,
> Thanks for your input here! A new method wouldn’t be worth adding purely for
> performance reasons then, but there is still an issue around semantics and
> locking.
Right.
> it doesn’t actually ensure the function is calle
On 4/29/2020 3:55 AM, Tom Forbes wrote:
Hey Raymond,
Thanks for your input here! A new method wouldn’t be worth adding purely for
performance reasons then, but there is still an issue around semantics and
locking.
One thing I don't understand about the proposed @call_once (or whatever
it's c
Hey Raymond,
Thanks for your input here! A new method wouldn’t be worth adding purely for
performance reasons then, but there is still an issue around semantics and
locking.
Should we encourage/document `lru_cache` as the way to do `call_once`? If so,
then I guess that’s suitable, but people ha
Oh, I didn't know this Python 3.8 new feature
(@functools.cached_property). It does exactly what I needed, cool!
Victor
Le mar. 28 avr. 2020 à 21:18, Brett Cannon a écrit :
>
> Victor Stinner wrote:
> > Hi,
> > A pattern that I used multiple times is to compute an object attribute
> > only once
> t...@tomforb.es wrote:
>
> 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.
It seems like you would get just about everything
Victor Stinner wrote:
> Hi,
> A pattern that I used multiple times is to compute an object attribute
> only once and cache the result into the object. Dummy example:
How is that different from
https://docs.python.org/3/library/functools.html?highlight=cached_property#functools.cached_property?
-
Hi,
A pattern that I used multiple times is to compute an object attribute
only once and cache the result into the object. Dummy example:
---
class X:
def __init__(self, name):
self.name = name
self._cached_upper = None
def _get(self):
if self._cached_upper is None
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 th
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 m
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 chang
> 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
(https://github.com/python/cpython/blob/cecf049673da6a24435acd1
On 27Apr2020 2237, t...@tomforb.es wrote:
2. Special casing "lru_cache" to account for zero arity methods isn't trivial and we
shouldn't endorse lru_cache as a way of achieving "call_once" semantics
Why not? It's a decorator, isn't it? Just make it check for number of
arguments at decoration
23 matches
Mail list logo
