python development practices?

[James_Althoff at i2.com]

Cliff Wells wrote:
>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.

Yep.  Sadly, the fragile base-class monster does raise its head and take a
bite now and again -- and it can be nasty.  And I agree that the _ doesn't
help because of the general need and desire for more than one level of
subclassing.  And this is true for methods that might be overridden
unintentionally in a subclass as well as for fields.

Jim