[Tim Peters] >> Sorry, I couldn't follow the intent there. Not obvious to me how >> moving this stuff from `threading` into `thread` would make it >> easier(?) for the implementation to wait for non-daemon threads to >> finish.
[Martin v. Löwis] > Currently, if you create a thread through the thread module > (rather than threading), it won't participate in the "wait until > all threads are done" algorithm - you have to use the threading > module. Moving it into the thread module would allow to cover all > threads. True, but that doesn't appear to have any bearing on the bug originally discussed. You introduced this as "yet another alternative" in the context of how to address the original complaint, but if that was the intent, I still don't get it. Regardless, I personally view the `thread` module as being "de facto" deprecated. If someone /wants/ the ability to create a non-daemon thread, that the ability is only available via `threading` is an incentive to move to the newer, saner module. Besides, if the daemon distinction were grafted on to `thread` threads too, it would have to default to daemonic (a different default than `threading` threads) else be incompatible with current `thread` thread behavior. I personally don't want to add new features to `thread` threads in any case. > Also, if the interpreter invokes, say, threading._shutdown(): > that's also "user-screwable", as a user may put something else > into threading._shutdown. To make it non-visible, it has to be > in C, not Python (and even then it might be still visible to > extension modules). The leading underscore makes it officially invisible <0.7 wink>, and users would have to both seek it out and go out of their way to screw it. If some user believes they have a need to mess wtih threading._shutdown(), that's fine by me too. The problem with atexit and sys.exitfunc is that users can get in trouble now simply by using them in documented ways, because `threading` also uses them (but inappropriately so, IMO). Indeed, that's all the `logging` module did here. While this next is also irrelevant to the original complaint, I think it was also a minor mistake to build the newer atexit gimmicks on top of sys.exitfunc (same reason: a user can destroy the atexit functionality quite innocently if they happen to use sys.exitfunc after they (or code they build on) happens to import `atexit`. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com