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

Anand Balachandran Pillai abpillai at gmail.com
Mon Sep 8 06:10:01 CEST 2008


On Sat, Sep 6, 2008 at 8:14 AM, Jesse Noller <jnoller at gmail.com> wrote:
> On Fri, Sep 5, 2008 at 10:38 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Jesse Noller wrote:
>>> 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:
>>>>> 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?.
>>>
>>> Also, FWIW, I thought we were no longer doing API changes?
>>
>> We aren't - if we'd thought of it a month ago, we could have included
>> it, but now 2.7/3.1 is the earliest for that change.
>>
>> As far as the 'typo protection' goes... I'm still not convinced that the
>> delayed action of the set daemon effect means that the Thread object
>> needs special protection.
>>
>> If an application fails to set the attribute properly, then its test
>> suite will hang on shutdown (as the threading module attempts to do
>> .join() on a thread that hasn't been told to stop).
>
> I happen to really like like the property-approach. It makes sense to
> call thread.daemon = True, it's also clean and feels natural now that
> it's there. And you're right - typos in this will bite people fairly
> quickly, but to Jesus' point - those people may go chasing something
> else before noticing they typed deamon instead of daemon.

I think Jesus raises a very valid point. I have often typed "setDeamon"
instead of "setDaemon" for my thread objects. I always make it a point
to keep open the module documentation for threading.Thread before
calling this method on the objects.

I think the "Pythonic" way of doing it would be to use properties,
so 'thread.daemon=1' is very nice. But without __slots__, we are
going to have many developers write 'thread.deamon=1' and not
notice this is the problem when they start debugging after stuff
does not work the way they expect at process shutdown. They
are going to chase after some other thread...

I guess adding __slots__ to Thread class is the best approach
for this. +1 for that...

IMHO, this is perhaps late for 3.0, but definitely a good thing
to add for 3.1.

>
> -jesse
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/abpillai%40gmail.com
>

Regards,

-- 
-Anand


More information about the Python-3000 mailing list