> On Apr 29, 2020, at 4:20 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
>
> On Wed, 29 Apr 2020 12:01:24 -0700
> Raymond Hettinger <raymond.hettin...@gmail.com> 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,
>> either block or fail :-(
>
> It definitely needs to block.
Do you think it is safe to hold a non-reentrant lock across an arbitrary user
function?
Traditionally, the best practice for locks was to acquire, briefly access a
shared resource, and release promptly.
>> 3) call the function, this cannot be reentrant :-(
>
> Right. The typical use for such a function is lazy initialization of
> some resource, not recursive computation.
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.
Presumably, the initialization function would have to take zero arguments, have
a useful return value, must be called only once, not be idempotent, wouldn't
fail if called in two different processes, can be called from multiple places,
and can guarantee that a decref, gc, __del__, or weakref callback would never
trigger a reentrant call.
Also, if you know of a real world use case, what solution is currently being
used. I'm not sure what alternative call_once() is competing against.
>>
>> 6) does not have instrumentation for number of hits
>> 7) does not have a clearing or reset mechanism
>
> Clearly, instrumentation and a clearing mechanism are not necessary.
> They might be "nice to have", but needn't hinder initial adoption of
> the API.
Agreed. It is inevitable that those will be requested, but they are incidental
to the core functionality.
Do you have any thoughts on what the semantics should be if the inner function
raises an exception? Would a retry be allowed? Or does call_once() literally
mean "can never be called again"?
Raymond
_______________________________________________
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/Y2MUKYDCV53PBWRRBU4ZAKB5XED4X4HX/
Code of Conduct: http://python.org/psf/codeofconduct/
