Erick <erick.peir...@gmail.com> added the comment:
> What are examples of your some_important_context()? Is it important to call > some code before destroying the thread? To be honest, pulled a context manager example out of thin air to illustrate the point. But sure, I want to allocate a resource before the thread runs, and release it when the work is done. > The problem with allowing the user to specify the Thread subclass is that in > general using Thread is an implementation detail. ThreadPoolExecutor could be > implemented using the low-level _thread module instead. Or in future it can > need to create a special Thread subclass, and user-specified Thread subclass > can be not compatible with it. This is surprising to hear, since I imagine that there are many potential users of this library that are evolving from direct wrangling of Thread objects, where custom Thread subclasses are commonplace. This was certainly the scenario that prompted me to post. Ultimately it's up to the maintainers what direction the library will go. Are there specific plans to adopt an alternative implementation that is orthogonal to `threading.Thread`? Or are there reasons to think that it is likely? I would submit that maintaining smooth interoperability between this library and the `threading` library would be a welcome constraint, absent specific drivers to the contrary. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45339> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
