[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Floris Bruynooghe floris.bruynooghe at gmail.com
Wed May 26 14:06:51 CEST 2010

Hi

On Sun, May 23, 2010 at 10:47:08AM +1000, Brian Quinlan wrote:

Jesse, the designated pronouncer for this PEP, has decided to keep discussion open for a few more days.

So fire away!

In thread.py the module automatically registers a handler with atexit. I don't think I'm alone in thinking libraries should not be doing this sort of thing unconditionally behind a user's back. I'm also not so sure how comfortable I am with the module-level globals.

Would it not be possible to have an exit handler on each thread pool which the documentation reccomends you register with atexit if it suits your application? I think that would get rid of the global singletons and hidden atexit in a fairly elegant way.

Lastly _base.py creates a LOGGER (connected to sys.stderr if I understand correctly) and only logs a critical message to it at the same time as a RuntimeError is raised. While I don't necessarily dislike that it uses a logger, I don't like that it's wired up to sys.stderr I rather think it's the application's duty to create a handler if it wants one. But given that it's only used at the same time as a RuntimeError it does seem redundant.

Regards Floris

PS: I've only looked at the threading part of the implementation.

-- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

More information about the Python-Dev mailing list