[Poll] Private variables

[Tim Peters]

[tanzer at swing.co.at]
> ...
> Well, when I found this "feature" it was not important enough to write
> up a complain. Besides, I figured the chances of it being changed were
> slim. Judging by the style of your answer I was right on target here
> <wink>.

It's not up to me, but no, I wouldn't change anything here.  Partly because:

> ...
> Just learned something new. I didn't know that any number of two or
> more leading `_` is considered private.

This is part of the problem:  *everything* about private names mentioned in
this thread has been a surprise to you.  You haven't read the docs, so I'm
not surprised that things don't work in all respects the way you assumed
they would.

>> You're unable to define a _Foo class and a Foo class in the same module
>> without accidentally overlapping their namespaces?

> How is the same module relevant for this issue?

I'm not sure -- for some reason I got the impression the classes in your
example were in the same module.  If not, I assumed more than you said.

> And what are `__` names for if not to avoid overlap of class namespaces?

As was clear when they were first discussed on c.l.py, they don't work for
that in all cases.  This isn't news, it was part of the design tradeoffs
deliberately made.  You're missing a much nastier case, BTW, where a base
class somewhere down in the graph just happens to have the same name as the
class indirectly deriving from it, so that no local name-mangling rule can
work, no matter how convoluted.

> I stumbled over this because I use `__Ancestor` to chain up method
> calls. [And don't tell me I should use `super` for this -- it's not
> yet there!]

Then, as I said last time (and hoped to make clearer above), if you want to
use this gimmick to achieve that, the burden is on you to choose class names
so that it works in the end.  I specifically suggested putting an underscore
on *both* sides of your (pseudo)private class names, and then Foo and _Foo_
mangle differently (whereas Foo and _Foo and ______Foo do not).  If you
wanted a solution instead of an argument, I expect you would have run with
that instead of snipping it <wink>.

> Promoting-a-wart-to-the-best-thing-since-sliced-bread-
>     smells-funny-ly y'rs,

I'm not:  I've told you and am telling you it's a simple hack, not the
foundation for a way of life.  It works fine if you play along with its
limitations; it doesn't work at all if you don't.

there's-no-substitute-for-learning-the-rules-ly y'rs  - tim