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