Why less emphasis on private data?

[Steven D'Aprano]

On Sun, 07 Jan 2007 23:49:21 -0800, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVEME.cybersource.com.au> writes:
>> Just how often do you inherit from two identically-named classes
>> both of which use identically-named private attributes?
> 
> I have no idea how often if ever.

You've established that there's a name conflict when you do so, which
leads to bugs. So how often do you get bitten by that particular type of
bug?


> I inherit from library classes all
> the time, without trying to examine what superclasses they use.  If my
> subclass happens to have the same name as a superclass of some library
> class (say Tkinter) this could happen.  Whether it ever DOES happen, I
> don't know, I could only find out by examining the implementation
> details of every library class I ever use, and I could only prevent it
> by remembering those details.

class MySubClass(SomeSuperclass):
    try:
        __my_private_attribute
    except AttributeError:
        __my_private_attribute = some_value
    else:
        raise ValueError("Name conflict with private attribute!")

Problem solved.

*wink*


> That is an abstraction leak and is
> dangerous and unnecessary.  The name mangling scheme is a crock.  How
> often does anyone ever have a good reason for using it, 

Exactly. I never use it.

The truth of the matter is, MyClass.__private is not private at all. It is
still a public attribute with a slightly unexpected name. In other words,
if you want to code defensively, you should simply assume that Python has
no private attributes, and code accordingly.

Problem solved.



-- 
Steven.