The connection is very obvious after you know about it.
And probably you can guess the meaning if you see an
@once decorator in someone's code. But it's less clear
that a person who hasn't seen the word "once" used
this way will think of searching for it when they want
a way to cache the return
> Does that sound good enough to dismiss the problem?
Sure, tangibly related issues with other implementations from a discussion in
the 00’s doesn’t seem like a fantastic argument, especially given that we use
this exact pattern already in the stdlib without issue:
Andrew, can you describe the memory model issue in detail?
Regards
Antoine.
On Fri, 1 May 2020 22:45:13 -0700
Andrew Barnert via Python-ideas
wrote:
> On May 1, 2020, at 09:51, Tom Forbes wrote:
> >
> >> You’ve written an exactly equIvalent to the double-checked locking for
> >>
On May 1, 2020, at 09:51, Tom Forbes wrote:
>
>> You’ve written an exactly equIvalent to the double-checked locking for
>> singletons examples that broke Java 1.4 and C++03 and led to us having once
>> functions in the first place.
>> … but what about on Jython, or PyPy-STM, or a future
> Risks: Any reentrancy or recursion will result in deadlock.
Reentrancy is a great point that I didn’t consider. I would say that as the
intended use case for this is returning lazy singletons of some kind then
reentrant calls would be a bug that would end with a recursion error - which is
> You’ve written an exactly equIvalent to the double-checked locking for
> singletons examples that broke Java 1.4 and C++03 and led to us having once
> functions in the first place.
> … but what about on Jython, or PyPy-STM, or a future GIL-less Python?
While I truly do appreciate your
On Apr 29, 2020, at 11:15, Tom Forbes wrote:
>
>> Thread 2 wakes up with the lock, calls the function, fills the cache, and
>> releases the lock.
>
> What exactly would the issue be with this:
>
> ```
> import functools
> from threading import Lock
>
> def once(func):
>sentinel =
> 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):
>sentinel = object()
>cache = sentinel
>lock = Lock()
>
>@functools.wraps(func)
>def _wrapper():
> Thread 2 wakes up with the lock, calls the function, fills the cache, and
> releases the lock.
What exactly would the issue be with this:
```
import functools
from threading import Lock
def once(func):
sentinel = object()
cache = sentinel
lock = Lock()
On 28/04/2020 23:58, Andrew Barnert via Python-ideas wrote:
Really, we either need descriptors that can somehow work for globals
and class attributes (which is probably not solveable), or some brand
new language semantics that aren’t built on what’s already there. The
latter sounds like probably
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
On Apr 28, 2020, at 16:25, Steven D'Aprano wrote:
>
> On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymond Hettinger wrote:
>
>> It seems like you would get just about everything you want with one line:
>>
>> once = lru_cache(maxsize=None)
>
> But is it thread-safe?
You can add thread
On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymond Hettinger wrote:
> It seems like you would get just about everything you want with one line:
>
> once = lru_cache(maxsize=None)
But is it thread-safe? If you have a "once"ed expensive function with
side-effects, and a second thread calls
On Apr 28, 2020, at 12:02, Alex Hall wrote:
>
> Some libraries implement a 'lazy object' which forwards all operations to a
> wrapped object, which gets lazily initialised once:
>
> https://github.com/ionelmc/python-lazy-object-proxy
>
Some libraries implement a 'lazy object' which forwards all operations to a
wrapped object, which gets lazily initialised once:
https://github.com/ionelmc/python-lazy-object-proxy
https://docs.djangoproject.com/en/3.0/_modules/django/utils/functional/
There's also a more general concept of
> On Apr 26, 2020, at 7:03 AM, Tom Forbes 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
On Apr 26, 2020, at 10:41, Guido van Rossum wrote:
>
>
> Since the function has no parameters and is pre-computed, why force all users
> to *call* it? The @once decorator could just return the value of calling the
> function:
>
> def once(func):
> return func()
>
> @once
> def pwd():
>
more complex.
Steve Barnes
-Original Message-
From: Oleg Broytman
Sent: 28 April 2020 10:05
To: python-ideas@python.org
Subject: [Python-ideas] Re: Adding a "once" function to functools
On Tue, Apr 28, 2020 at 10:19:49AM +0200, Antoine Pitrou
wrote:
> On Tue, 28 Apr 2020
> On 28 Apr 2020, at 02:04, Steven D'Aprano wrote:
>
> Yes, it's annoying when English words can have two or more meanings. The
> first time I can across math.sin, I was very excited, until I realised
> it was just the trigonometric function :-(
@once
def my_func():
...
I read
On Tue, Apr 28, 2020 at 10:19:49AM +0200, Antoine Pitrou
wrote:
> On Tue, 28 Apr 2020 11:04:15 +1000
> Steven D'Aprano wrote:
> >
> > Yes, it's annoying when English words can have two or more meanings. The
> > first time I can across math.sin, I was very excited, until I realised
> > it was
On Tue, 28 Apr 2020 11:04:15 +1000
Steven D'Aprano wrote:
>
> Yes, it's annoying when English words can have two or more meanings. The
> first time I can across math.sin, I was very excited, until I realised
> it was just the trigonometric function :-(
>
> This is the gunslinger.draw versus
On 28/04/20 1:17 pm, Steven D'Aprano wrote:
I think
that it is silly to say that you have to be familiar with Eiffel to
recognise the connection between running a function once and the word
"once".
The connection is very obvious after you know about it.
And probably you can guess the meaning
On Sun, Apr 26, 2020 at 09:58:46PM -0400, Dan Sommers wrote:
> > How many beginners do you know who even know what a LRU cache is?
>
> The same number of beginners who know to look in functools for a
> decorator called once?
Look in *functools* at all? Probably not that many.
Google for "how
On Tue, Apr 28, 2020 at 12:40:34PM +1200, Greg Ewing wrote:
> I don't think "once" is a bad name, but we shouldn't kid
> ourselves that it will be intuitive or discoverable to
> anyone who isn't familiar with Eiffel.
I'm not particularly wedded to "once" specifically, but honestly I think
that
On Mon, Apr 27, 2020 at 07:58:54AM -0700, Ethan Furman wrote:
> On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
> >On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
>
> >>How many beginners know they want to call a function only once?
> >
> >More than the number who know about LRU
On 28/04/20 6:34 am, Antoine Pitrou wrote:
A more explicit spelling would be `@call_once`,
what do you think?
That's not quite right either -- you're allowed to *call* it
as many times as you want. It's more like "execute once".
But that's a rather long and awkward name.
I don't think "once"
Thank you Kyle and everyone else who chimed in here. I’ve made a post to the
python-dev mailing list - it has yet to appear, but perhaps it’s in a
moderation queue. I’ll ensure it’s posted tomorrow.
Tom
> On 27 Apr 2020, at 21:56, Kyle Stanley wrote:
>
> Christopher Barker wrote:
>> Is there
Christopher Barker wrote:
> Is there a core developer with a particular interest in functools to be
> consulted?
Yep, Raymond Hettinger is the designated expert for the functools
module. See https://devguide.python.org/experts/#stdlib. I'm not sure
as to whether he regularly checks
I'd like to give my explicit +1 on this proposal, and for the
suggested alternative name "call_once". To me, this seems to be the
case of a common small startup optimization that's very easy to get
wrong, and to many users may be too much of a hassle to write their
own implementation to be worth
On Mon, Apr 27, 2020 at 12:26 PM Antoine Pitrou wrote:
> My own opinion is that it's limited enough in scope (and probably
> uncontroversial implementation-wise) that it doesn't need a PEP. Of
> course other core developers may disagree, so perhaps wait a few days
> before submitting a PR :-)
>
My own opinion is that it's limited enough in scope (and probably
uncontroversial implementation-wise) that it doesn't need a PEP. Of
course other core developers may disagree, so perhaps wait a few days
before submitting a PR :-)
Regards
Antoine.
On Mon, 27 Apr 2020 20:16:53 +0100
Tom
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
On 04/27/2020 11:34 AM, Antoine Pitrou wrote:
On Mon, 27 Apr 2020 09:26:53 -0700 Ethan Furman wrote:
That is what I was saying -- that `once`, all by itself, could mean multiple
things.
That's a good point. A more explicit spelling would be `@call_once`,
what do you think?
I think
On Mon, 27 Apr 2020 09:26:53 -0700
Ethan Furman wrote:
>
> > Or are you saying that once could be interpreted to mean I cannot do that
> > 2nd def?
>
> That is what I was saying -- that `once`, all by itself, could mean multiple
> things.
That's a good point. A more explicit spelling
On 04/27/2020 08:26 AM, Barry wrote:
On 27 Apr 2020, at 16:01, Ethan Furman wrote:
I'm objecting to using "beginners" as the basis for name choices for advanced
topics.
Aside from that, `once` is a fine name. I'm sure it means that a function can
only be defined once, and subsequent
> On 27 Apr 2020, at 16:01, Ethan Furman wrote:
>
> On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
>> On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
>
>>> How many beginners know they want to call a function only once?
>> More than the number who know about LRU caches.
>>
On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
How many beginners know they want to call a function only once?
More than the number who know about LRU caches.
Ethan, are you objecting to a self-descriptive name because it is too
On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
> >How many beginners do you know who even know what a LRU cache is?
>
> How many beginners know they want to call a function only once?
More than the number who know about LRU caches.
Ethan, are you objecting to a self-descriptive
On Mon, Apr 27, 2020 at 12:51 PM Ethan Furman wrote:
>
> On 04/26/2020 05:11 PM, Steven D'Aprano wrote:
> > On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
> >
> >> It's not clear to me why people prefer an extra function which would be
> >> exactly equivalent to lru_cache in the
On 04/26/2020 05:11 PM, Steven D'Aprano wrote:
On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
It's not clear to me why people prefer an extra function which would be
exactly equivalent to lru_cache in the expected use case (i.e. decorating a
function without arguments). It seems
On Mon, 27 Apr 2020 10:11:01 +1000
Steven D'Aprano wrote:
> On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
>
> > It's not clear to me why people prefer an extra function which would be
> > exactly equivalent to lru_cache in the expected use case (i.e. decorating a
> > function
On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
> It's not clear to me why people prefer an extra function 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,
>
On Sun, Apr 26, 2020 at 05:31:22PM +0100, Tom Forbes wrote:
> > What if the functions requires arguments? How to cache calls with
> > different arguments? What if some arguments are not hashable?
>
> Then I think lru_cache is perfectly suitable for that use case. `once()`
> would only be useful
While the implementation is great, including locking to ensure the underlying
function is called only once, this only works for properties rather than
methods defined in modules (and more generally, any method).
> On 26 Apr 2020, at 20:27, Matthew Einhorn wrote:
>
> On Sun, Apr 26, 2020 at
On Apr 26, 2020, at 10:49, Eric Fahlgren wrote:
>
>> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
>> It's not clear to me why people prefer an extra function which would be
>> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
>> function without arguments). It
On Sun, Apr 26, 2020 at 1:54 PM Tom Forbes 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 instantiated
> until the Django
On Sun, Apr 26, 2020 at 7:47 PM Eric Fahlgren
wrote:
> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
>
>> It's not clear to me why people prefer an extra function which would be
>> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
>> function without arguments). It
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 instantiated until the Django
settings have been loaded, which rules out calling them from
On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
> It's not clear to me why people prefer an extra function 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
Since the function has no parameters and is pre-computed, why force all
users to *call* it? The @once decorator could just return the value of
calling the function:
def once(func):
return func()
@once
def pwd():
return os.getcwd()
print(pwd)
On Sun, Apr 26, 2020 at 7:09 AM Tom Forbes
On Sun, Apr 26, 2020 at 6:57 PM Tom Forbes wrote:
> I agree, that was the topic of my original post to the python-ideas
> discussion group[1]. I thought we should special-case `lru_cache()` to
> account for this use case.
>
> The general consensus was that a `once()` decorator would be less
>
I agree, that was the topic of my original post to the python-ideas discussion
group[1]. I thought we should special-case `lru_cache()` to account for this
use case.
The general consensus was that a `once()` decorator would be less confusing and
more semantically correct than using `lru_cache`
It's not clear to me why people prefer an extra function 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
What if the functions requires arguments? How to cache calls with
different arguments? What if some arguments are not hashable?
Then I think lru_cache is perfectly suitable for that use case. `once()`
would only be useful if you’re calling a function with no arguments and
therefore return a
On 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 with subsequent calls. My
I have needed this often enough (and used `lru_cache` ) to say I am
full +1 on it. It should not hurt have `functools.once`.
On Sun, 26 Apr 2020 at 11:09, Tom Forbes wrote:
> Hello,
> I would like to suggest adding a simple “once” method to functools. As the
> name suggests, this would be a
56 matches
Mail list logo
