On 12May2022 20:17, Barney Stratford <barney_stratford@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 <cs@cskk.id.au>