[Python-Dev] Re: Starting a new thread
On Tue, 10 May 2022 16:12:13 +0100 Barney Stratford wrote: > Hello all. > > It occurs to me that creating threads in Python is more awkward than it needs > to be. Every time I want to start a new thread, I end up writing the same > thing over and over again: > > def target(*args, **kwds): > ... > t = threading.Thread(target = target, args = , kwargs= ) > t.start() > > This becomes especially repetitive when calling a target function that only > makes sense when run in a new thread, such as a timer. > > In my own code, I’ve taken to decorating functions that always run in new > threads. Then I can call the function using the usual function call syntax, > and have the new thread returned to me. With the decorator, the code reads > instead: > > @threaded > def target(*args, **kwds): > … > t = target(*args, **kwds) > > This has a couple of advantages. I don’t have to import the threading module > all over my code. I can use the neater syntax of function calls. The > function’s definition makes it clear it’s returning a new thread since it’s > decorated. It gets the plumbing out of the way so I can concentrate more on > what my code does and less in how it does it. > > It feels like the right place for this decorator is the standard library, so > I’ve created PR #91878 for it. @rhettinger suggests that this is a bit > premature, and that we should discuss it here first. Thoughts? This seems like an attractive nuisance. Creating threads comes with its own constraints and subtleties. I don't think it really helps users to hide it behind a "regular" function call. Like Greg I'm leaning towards -1 on this. Regards Antoine. ___ 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/7XXVN7GOBWUFORMDLHQGLFIYZH23IXA2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Starting a new thread
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? Cheers, Barney. ___ 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/Z4AWYWNHJGOSBBU6DFV3ZS26WWQIILMW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Starting a new thread
It’s definitely too early for a PR, so if you already have one (I didn’t see one linked to this thread) please close it. Then once we’ve bikeshedded the right good idea you can start a new PR. On Thu, May 12, 2022 at 12:21 Barney Stratford 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? > > Cheers, > Barney. > ___ > 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/Z4AWYWNHJGOSBBU6DFV3ZS26WWQIILMW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ 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/YXGV6WQYHEKJWJGES6LS7DNUB5WFOVCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Starting a new thread
On 12May2022 20:17, Barney Stratford 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 ___ 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/
[Python-Dev] Re: Starting a new thread
10.05.22 18:12, Barney Stratford пише: This has a couple of advantages. I don’t have to import the threading module all over my code. I can use the neater syntax of function calls. The function’s definition makes it clear it’s returning a new thread since it’s decorated. It gets the plumbing out of the way so I an concentrate more on what my code does and less in how it does it. I do not see advantages. You definitely need to import the threading module or other module depending on the threading module in which you define the decorator. And you need to decorate the function. It will not save you a line of code. If you need to run a lot of functions in threads, note that a thread has some starting cost. Consider using concurrent.futures.ThreadPoolExecutor. If you only run few long living threads, the syntax of starting them does not matter, in comparison with the rest of your code. Also, it looks wrong to me to mix two different things: what code to execute and how to run it. If we need a neater syntax, I would propose: t = threading.start_thread(func, *args, **kwargs) But I am not sure that it is worth to add such three-line function in the stdlib. ___ 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/RBIAWP2J3NTYMLIS3W6CKX44G5QIBXAU/ Code of Conduct: http://python.org/psf/codeofconduct/
