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/
