python development practices?

Cliff Wells logiplexsoftware at earthlink.net
Wed Oct 31 16:11:21 EST 2001


On Wednesday 31 October 2001 12:20, James_Althoff at i2.com wrote:

> Absolutely!  The ability to change a class implementation whilst preserving
> backwards compatibility via the safety net of method access has saved the
> derriere on numerous occasions.  (The very notion of hard-coded access to
> instance variables strewn about in random pieces of code in a large system
> just flat-out gives me the willies.  For me, the really important thing is
> actually *to buy into* the idea of encapsulation).

Encapsulation is as much a part of data hiding as private variables.  
However, it would be nice to have a mechanism so that derived classes 
wouldn't have to be careful of accidentally stepping on the attributes of 
base classes.  As I said earlier, a class should be a "black box".  Authors 
of derived classes shouldn't have to look at the internals of base classes to 
avoid this, especially since, as we were discussing, the internals of the 
base class could conceivably change, introducing name-collisions in derived 
classes.  A single underscore will not prevent this.  For instance:

class Base:
    def __init__(self):
        self._foo = 1

class Derived(Base):
    def __init__(self):
         Base.__init__(self)
         self._x = 1
         self._y = 2

No problem here, but later, the author of Base decides to add a self._x to 
Base.  Now Derived is undoubtedly broken and it won't be clear why.  A 
private variable mechanism that could prevent this scenario would be a 
definite benefit. 

Regards,

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308




More information about the Python-list mailing list