On Tue, May 10, 2022 at 10:34 AM Barney Stratford < barney_stratf...@fastmail.fm> wrote:
> > 1. Does t = target(...) start the thread? I think it does. > I think it does too. In the commonest use case, immediately after creating > a thread, you start it. And if you want to delay the thread but still use > the decorator, then you can do that explicitly with some locks. In fact, > it’s probably better to explicitly delay execution than have hidden > requirements concerning the timing of thread creation and startup. > > > 2. Is it possible to create daemon threads? > Not at the moment. I did think about this, but felt that simpler is > better. Like you say, it’d be easy to add. In fact, I might just go ahead > and add it to the PR in a bit. The simplest way to do it is probably to > define a second decorator for daemonic threads. > If this is even to be added (i personally lean -1 on it), I suggest intentionally not supporting daemon threads. We should not encourage them to be used, they were a misfeature that in hindsight we should never have created. Daemon threads can lead to very bad surprises upon interpreter finalization - an unfixable problem given how daemon threads are defined to behave. > 3. Can you create multiple threads for the same function? I assume t1, > > t2, t3 = target(arg1), target(arg2), target(arg3) would work. > That’s exactly what I had in mind. Make it so that thread creation and > function call look exactly alike. You can call a function as many times as > you want with whatever args you want, and you can create threads as often > as you want with whatever args you want. > > There isn’t a single use case where the decorator is particularly > compelling; rather, it’s syntactic sugar to hide the mechanism of thread > creation so that code reads better. > This is my take as well. I don't like calling code to hide the fact that a thread is being spawned. Use this decorator and if you fail to give the callable a name communicating that it spawns and returns a thread, you will have surprised readers of the calling code. A nicer design pattern is to explicitly manage threads. Use concurrent.futures.ThreadPoolExecutor. Or use the async stuff that Joao mentioned or similar libraries. I think we already provide decent batteries with the threading APIs. -gps
_______________________________________________ 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/3I7GBDGMHU4BHHR57EFOL6B4JMURFSGE/ Code of Conduct: http://python.org/psf/codeofconduct/
