[Python-Dev] Re: Integrating timeoutsocket.py
Sun, 28 Apr 2002 11:15:13 -0400
Sure. I'll work on this patch. Should I log the bug into SF tracker
as well? I agree that it would be nice to have some sort of overridden
method at that point. The decision just has to be whether or not
t.setDaemon (1) should be the default. The warning is a good idea. I
think the setDeamon default is what previous users expect.
On Sun, Apr 28 @ 09:09, Guido van Rossum wrote:
> > > Found the cause in ServerSocket.py. You need to add the line:
> > >
> > > t.setDaemon (1)
> > >
> > > at line 469 in ServerSocket.py, right after the thread is
> > > created. Whether this is an error is debatable though.
> > Since this is a semantics change, you need to make this operation
> > optional - either by passing parameters, or by checking state of some
> > object.
> One option would be to insert a call to a hook method at that point.
> Define the hook to do nothing in the base class. Theyn your own class
> can override the hook to call t.setDaemon(1). The hook should
> probably be called with the thread object (t) as its argument.
> > If you think the setDaemon call should be the default, you can then
> > deprecate the case where the application does not explicitly specify
> > the daemon behaviour (with a deprecation warning (*)), but continue to
> > operate in this case as today - in a future version of Python (say,
> > 2.5), the default can then be changed.
> > Want to work on a patch?
> > Regards,
> > Martin
> > (*) Triggering the deprecation warning just often enough is tricky. In
> > this case, I would trigger it once per implementation class.
> The default hook could include a call to warnings.warn(). This would
> only trigger once per program, but I bet that's a good approximation
> of once per implementation class. :-)
> --Guido van Rossum (home page: http://www.python.org/~guido/)
For my gpg public key: