Zope & Python

Tim Peters tim_one at email.msn.com
Mon Sep 18 00:38:35 EDT 2000


[Grant Griffin]
> You know...I've played the private/public/protected game in C++
> faithfully for about five years (though mostly in private <wink>), but
> in retrospect, I just really can't see much point to it.  (And don't
> even get me started on that bogus "friend" thing--with a friend like
> that, who needs enemies? <wink>)
>
> The only thing of all of that I can see any real point to now is
> "private", which I use to mean "this stuff is Plutonium; pure toxic
> nuclear waste; the most deadly substance on the planet: don't touch it
> unless you're trying to save the good people of Chernyobl, at the
> possible cost of your own life".

In "The Design and Evolution of C++", Stroustrup relates that he didn't like
"protected" at first sight, or second or third, but eventually gave in to
relentless "good arguments" in favor of it.  After it got implemented and
used, he saw no good use for it in practice, noted that the chief proponent
stopped using it, and wished he could take it out.

Which just goes to show again that the man has no sense of humor <wink>:  at
the time he let "protected" get in, he should *also* have insisted on
adding, say, "volatile protected", "const private", and "public protected
private public" (+ the other 80 of that ilk).  I'm sure that if he had, we'd
see dozens of books now explaining the crucial differences among all of them
<0.7 wink>.

As to friends, what's the problem?  It's better to avoid them when you can,
but in a language without multimethods it's a fine way to let (possibly
overloaded) functions get at the guts of all involved classes.

> I think Python has some sort of convention or system for that, but I've
> never used it.

Both, really.  The convention for indicating a private name is to begin it
with a single underscore.  That has no teeth at all -- it's pure honor
system.  The stronger gimmick, which does have some baby teeth, is to begin
a name with two underscores.  Some name-mangling is done at compile-time to
ensure that such names can't be trivially gotten at from outside the class
in which they appear.  That's got another use, too, in deep class
hierarchies (not common either in Python!), just to avoid name collisions:
if A derives from B (well, even if it doesn't!), __name in the scope of
class A is literally a different string than __name in the scope of class B,
thanks to the compile-time name-mangling.

theoretically-unsound-yet-perfect-in-practice-ly y'rs  - tim





More information about the Python-list mailing list