On 12May2022 20:17, Barney Stratford <barney_stratf...@fastmail.fm> wrote:
>It seems like the consensus is that this is a good idea, but it’s the
>wrong good idea. Should I cancel the PR or should we try to make it
>into a better good idea?
Why not shift slightly? As remarked, having a function automatically
spawn threads can be confusing, because spawning a thread has
implications for both the thread code itself and for the person calling
the function. The caller might find that confusing or complex.
Personally, my approach has been a tiny shim function named "bg" in my
personal kit, to make it easy to spawn a regular function in a thread:
T = bg(func, args....) # returns a running Thread
An approach I've also seen is Celery's one of decorating a function with
attributes which can dispatch it as a task, roughly:
@task
def regular_function(.....)
...
and it can be dispatched by saying regular_function.defer(......) and
variations.
Some downsides to decorators include:
- only decorated functions can be kicked off "automatically as threads";
that could be a good thing too
- the decorator wires in the dispatch mechanism: your decorator spawns a
thread, the Celery @task queues to a Celery task queue, and so forth
So my personal inclination is to provide an easy to use shim for the
caller, not the function. Eg:
from cs.threads import bg
.....
T = bg(func, args.....)
or:
from cs.threads import bg as bg_thread
from cs.later import bg as bg_later
.....
T = bg_thread(func, args......) # run in a Thread
.....
R = bg_later(func, args.......) # hand off to a Later, get a Result for
collection
......
bg = bg_later # specify the queuing system
......
... do stuff via bg(), the chosen queuing system ...
or whatever other queuing system you might be using. The idea here is to
make it easy to submit a function to any of several things rather than
decorating the function itself to submit to a now-hardwired thing.
Just things to consider....
Cheers,
Cameron Simpson <c...@cskk.id.au>
_______________________________________________
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/BX6J7BKEXMNQFARDKMKDSKAS7VTOVPIP/
Code of Conduct: http://python.org/psf/codeofconduct/
