Privacy and Inheritance

[Jay O'Connor]

In article <mailman.1031112136.4594.python-list at python.org>, "Dennis B."
<dcswest at flashmail.com> wrote:

> Greetings;
> 
> Have enough confidence in Python to realize this is probably just my
> misunderstanding, but wondering why Python mangles private, double
> underscore attributes with the name of the base class even if they're
> inherited and the instance is that of the sub class.
> 
> Like the following doesn't even seem to work:
> 
> class StandardNormal:
> 
>     def letEventZScore(self, eventZScore):
>         self.__eventZScore = float(eventZScore)
> 
> class DerivativeNormal(StandardNormal):
> 
>     def getCentral(self):
>         if self.__eventZScore < 0:
> 
> Unless I change that last line to something like:
> 
>         if self._StandardNormal__eventZScore < 0:
> 
> Maybe just missing the point all together, but wondering if anyone'll
> point out anything a little more elegant and/or intuitive.
> 
> Thank you and have a great day,

Coming from a Smalltalk background, myself, which does not have anything akin to
'protected' and 'private', rather than a C++ background I would say the
real solution is "don't bother" :)

Code is communication...between you and the machine, but also between you
and other developers.  Sometimes communicating your intent through
convention to other developers is more important than communicating your
intent through syntax to the compiler.  Idon't really care as much about
getting the compiler to *enforce* what I want in ptotected or private
access as I do in telling other developers my intention of protectedness.

The convention seems to be that a leading underscore (_foo) implies that
the variable or function is not meant for public access.  You're still
free to reference it if you want, but you've been warned that it's not
recommended and you are on your own.

Like calling sys.exit() vs sys._exit(), both are legal, but you shouldn't
use the second flippantly as it has certain ramifications you shold be
aware of.

This allows developers to communicate their intention of how their code
should be used, without mucking up the language syntax and rules with a
lot of requirements for how to handle 'protectedness'

It's a different philosophy than in C++ or Java, but I think to be
effective in Python, it would be good to adopt that philosophy

-- 
Jay O'Connor
joconnor at cybermesa.com
http://www.r4h.org/r4hsoftware