Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :
> On Jun 5, 4:53 am, Bruno Desthuilliers <bruno.
> 42.desthuilli... at websiteburo.invalid> wrote:
>> Russ P. a écrit :
> 
>> Given your very recent discovery of what 'dynamic' *really* means in
>> Python (like, for exemple, dynamically adding / replacing attributes -
>> including methods - on a per-class or per-instance basis), possibly, yes.
> 
> My "very recent" discovery? Funny, I thought I knew that several years
> ago. 

Looks like I mistook your
"""
I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition
"""

as "I just realized (...)"

Sorry for having read too fast.

>>> I also realize, by the way, that Python allows a client of a class to
>>> define a new class member from completely outside the class
>>> definition. Obviously, that cannot be declared private.
>> Why so ?
> 
> Why should the client of a class not be able to declare a *private*
> member of the class? You're kidding, right?

I'm dead serious. I often add implementation attributes to either a 
class or an instance. These *are* implementation parts, not API.

> Do you mind if I tell you
> how to arrange the furniture in your bedroom?

I must be a bit dumb, but I don't see how human interaction problems 
relate to enforced access restriction in an OO programming language.

>>> But if the
>>> same identifier is already declared private within the class, than the
>>> new definition should not be allowed (because it would defeat the
>>> whole idea of "private" class members).
>> Why so ?
>>
>> Metaprogramming (including monkeypatching) is part of the pythoneer's
>> toolbox, and while it's not something to use without pretty good
>> reasons, it has many times proven to be a real life saver. In languages
>> not allowing it, the solutions to the class of problems easily solved by
>> monkeypatching happens to be at best a kludge, at worst plain
>> unsolvable, at least without too much effort to be even worth it. Your
>> above proposition would arbitrarily make possible and useful things
>> either uselessly complicated or near impossible.
> 
> For the record, I have made it abundantly clear that I don't think
> Python should not have as rigorous an encapsulation regime as C++ or
> Java. The worst that could happen with my proposition is that you
> would need to use a "mangled" name to access private data or methods.

That's already the case - when you use __name_mangling. And if there's 
no effective access restriction, then what the point of having this 
'priv' keyword ?

> But you will be using the name many times, you can reassign your own
> name, of course, so the mangled name need not appear more than once
> where it is needed.

Once again, I just don't see the point. Either you want effective access 
restriction in Python, or you don't. And if you don't, what would this 
'priv' keyword be useful to ?