Here comes a little add-on for python's threading library: It provides a way of reading a thread function's result after the termination. after a thread, which was created using safe_result = True as a constructor parameter, the thread object will gain the function result as a parameter, called "result". If the thread function did not return till the result attribute access, an AttributeError is raised.
I'm not sure this is generally useful. It might be sometimes, but it seems to me that it would often be insufficient for many tasks. There are many different ways that someone could get a result back from a thread; a Queue, a callback, being all sexy with pydispatcher, or many other ways. Since there are so many different approaches to this job, each with strengths and weaknesses in a specific situation, and none that are 'generally' useful over a broad range of activities, I don't think adding this one particular method to the core is a good idea. It's an ASPN Python Cookbook recipe for a threading.Thread subclass. E.g., I'm recommending this patch be rejected. P.S. Should that make me feel like a bad person? -.-
why would we throw the thread function result out of the window? because there is a another way, to do it? there are always many ways, how to do it, so why would we want to do it very difficult way? i think that not having the result stored somewhere is a bug and i'm voting for fixing it
I agree with Stephen. You can implement this functionality easily through the current API (subclassing), so there's no need to complicate the existing API to handle this one communication method as a special case. Furthermore, this particular use case is the tip of a small iceberg usually called "Futures", which provides a much cleaner API for the use case. There has been a suggestion to include such a package in core, though it will probably be some time before the library is mature enough for a decision to be made.
i still do not agree, it will always feel somehow incomplete, being able to easily "threadize" the function: >>> t = threading.Thread(target=func) and then not being able to get the target function result (easily)
