[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