[Python-3000] About "daemon" in threading module

[Jesse Noller]

On Fri, Sep 5, 2008 at 12:10 PM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nick Coghlan wrote:
>> Guido van Rossum wrote:
>>> On Thu, Sep 4, 2008 at 8:47 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>>> Jesus Cea <jcea <at> jcea.es> writes:
>>>>> First we had "thread.setDaemon()". This was not PEP8, so Python 3.0
>>>>> renamed it to "thread.set_daemon()". Lately Python 3.0 changes the
>>>>> method to an attribute "thread.daemon".
>>>>>
>>>>> I think the last change is risky, because you can mistype and create a
>>>>> new attribute, instead of set daemon mode. Since daemon mode is only
>>>>> usually visible when things goes wrong (the main thread dies), you can
>>>>> miss the bug for a long time.
>>>> I've never understood why the "daemon" flag couldn't be passed as one of the
>>>> constructor arguments. It would make code shorter, and avoid the mistyping risk
>>>> mentioned by Jesus. It also sounds saner, since you shouldn't change the flag
>>>> after the thread is started anyway.
>>> As to the why question, this was done to match the Java Thread class.
>>> I don't want to speculate why the Java API was designed this way --
>>> possibly it was a relic of an earlier API version in Java, but
>>> possibly there's a reason I can't fathom right now. After all, there
>>> are excellent reasons why start() is a separate call...
>>
>> Hmm, having (daemon=False) as a parameter on start() would probably be
>> an even better API than having it on __init__() (modulo subclassing
>> compatibility concerns).
>
> Agreed. Could it be done for 3.0?.

Personally, I'm staunchly against changing the __init__ for the
threading.Thread and multiprocessing.Process modules - it does
break/make more confusing the common subclassing people do.

I do like the idea of using __slots__, or reverting back to a
set_method entirely.

-jesse