[Python-Dev] PEP 8 and optional underscores
Nick Coghlan
ncoghlan at gmail.com
Fri Jun 13 10:54:12 CEST 2008
skip at pobox.com 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 | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
More information about the Python-Dev
mailing list