[EMAIL PROTECTED] wrote:
I'm not fond of using a property for this since it can lull you into the
false belief that what you are doing is less expensive than it really is
(attribute access vs method call). I think this is a case where explicit is
better than implicit.
Have you looked at what the methods we're proposing to turn into
properties are actually doing?:
def getName(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__name
def setName(self, name):
assert self.__initialized, "Thread.__init__() not called"
self.__name = str(name)
def getIdent(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__ident
def isAlive(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__started.isSet() and not self.__stopped
def isDaemon(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__daemonic
def setDaemon(self, daemonic):
if not self.__initialized:
raise RuntimeError("Thread.__init__() not called")
if self.__started.isSet():
raise RuntimeError("cannot set daemon status of active
thread");
self.__daemonic = daemonic
Checking whether or not an Event is set is hardly an expensive operation
and well within the limits of what I think it is reasonable for a
property access to do implicitly (e.g. it would also be reasonable for a
thread safe object to acquire and release a synchronisation lock while
retrieving or changing an attribute).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
