[Poll] Private variables

Tim Peters tim_one at email.msn.com
Sun Sep 16 05:40:17 EDT 2001


[Tim, on Ref Man section 5.2.1 (Identifiers -- Private name mangling)]

[tanzer at swing.co.at]
> When was this documentation added?

You can answer this as easily as I can -- it requires digging into the CVS
history of ref5.tex (quickest is to do a CVS Annotate on SourceForge, using
the ViewCVS web interface).

> I don't remember reading that (back in 1.5.x times; of course, my brain
> might just have chosen to selectively ignore it).

Or perhaps you never saw it.  It's in revision 1.17 of ref5.tex, though,
which predates 1.5.2 alpha 1.  Tracing back further than that is difficult,
because the Ref Man was also maintained under Framemaker before then, and
there's no CVS history for that.

> Feature or bug, it still is an example of feature interaction waiting
> to spring surprises on you.

Maybe.  This is the first time I heard of anyone having trouble with this,
so I'm afraid I rank it somewhere below dividing by 0 accidentally <wink>.

> ...
> I understand the difficulty. I still think it would have been better
> to just use a different (and documented) mangling scheme for class
> names starting with a single underscore (like ___A_beep <shudder>).

Exactly the same difficulty:  that still looks like a private name (which
begin with at least two underscores, not exactly two), so would be subject
to further mangling when written literally.

> ...
> My use of `__` names isn't motivated by privacy. The `__` names work
> well to allow each class in the hierarchy to have its own unique
> variables if it chooses so -- that is handy for some design patterns.
> That this variables are open for inspection is a bonus, IMHO.
>
> My consequence is to never use `_Foo` class names. Too bad, that that
> means that some classes might be imported by `from X import *` when
> I'd rather they wouldn't.

You're unable to define a _Foo class and a Foo class in the same module
without accidentally overlapping their namespaces?  And unable to think up
class names that differ in more than just the presence of leading
underscores?  If so, you can use __all__ to limit import-* visibility now
instead.  Or you could name your classes Foo and _Foo_, etc.

> Some-features-are-warts-even-if-documented-ly y'rs
> Christian

"mangling"-is-as-its-name-implies-a-simple-gimmick-not-a-foundation-
    for-a-way-of-life-ly y'rs  - tim





More information about the Python-list mailing list