[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