Guido van Rossum wrote:
> On Thu, Sep 4, 2008 at 8:47 AM, Antoine Pitrou <[EMAIL PROTECTED]> 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).
Regarding Jesus concern, you can always call t._set_daemon(True) and
t._set_name(whatever) if you want the extra defence against typographic
errors. The potential for mistyping attribute names is hardly a problem
that is unique to threading.Thread.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
