[Python-Dev] PEP 3148 ready for pronouncement

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