Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Joe P. Cool a écrit :
> On 24 Mai, 15:58, Ben Finney <bignose+hates-s... at benfinney.id.au>
> wrote:
>> Sh4wn <luckyluk... at gmail.com> writes:
>>> first, python is one of my fav languages, and i'll definitely keep
>>> developing with it. But, there's 1 one thing what I -really- miss:
>>> data hiding. I know member vars are private when you prefix them with
>>> 2 underscores, but I hate prefixing my vars, I'd rather add a keyword
>>> before it.
>> From whom are you trying to hide your attributes?
> 
> I saw this "don't need it" pattern in discussions about the ternary
> "if..else" expression and about "except/finally on the same block
> level".
> Now Python has both. Actually it is very useful to be able to
> distinguish
> between inside and outside.

Doing it the Python way makes the distinction pretty obvious : 
implementation stuff names all start with an underscore. You just can 
not miss it.

> This is obvious for real world things e.g.
> your
> TV. Nobody likes to open the rear cover to switch the channel.

Nope, but when the switch is broken and the TV not under warranty no 
more, I'm glad I can still open the rear cover and hack something by 
myself, despite usual (and hard to miss) "no user serviceable parts 
inside" and "warranty void if unsealed" warning stickers.


> Similar
> arguments apply to software objects. "data hiding" is a harsh name, I
> would
> call it "telling what matters".

Which is exactly what we do using naming convention.

>> In Python, the philosophy "we're all consenting adults here" applies.
> 
> Please don't sell a missing feature as a philosophy. Say you don't
> need/want
> it. But don't call it philosophy.

Please understand that not having access restriction is a design choice, 
not a technical inability (and FWIW the rationale behind that design 
choice has been debated to hell and back). So yes, it's is actually a 
'philosophic' problem.

>> You shouldn't pretend to know, at the time you write it, all the uses
>> to which your code will be put.
> 
> It's *your* *decision* which uses will be available. Your explanation
> appears
> to me as a fear to decide.

Nope, just a matter of experience.

>> If you want the users of your code to know that an attribute should
>> not be used as a public API for the code, use the convention of naming
>> the attribute with a single leading underscore.
> 
> Littering your class definition with dozens of underscores is exactly
> the
> line noise we love to criticize in Perl.

At least it makes what's 'inside' and what's 'outside' very obvious, 
isn't it ?

>>> Python advertises himself as a full OOP language, but why does it
>>> miss one of the basic principles of OOP?
>> Who taught you that enforced restrictions on attribute access was a
>> "basic principle" of OO?
> 
> Nearly every introduction to OOP?

Nearly every introduction to OOP is crap. Nearly every introduction to 
OOP also introduces classes and inheritance as "basic principle" of OO. 
Almost none introduction to OOP actually talk about *objects* - instead, 
they introduce mostly what Stroustrup and Gostling understood of OOP.

> Please don't tell me that
> encapsulation
> does not mean "enforced restriction".

What about : "encapsulation does not mean *language enforced* 
restriction" then ?

To me, encapsulation means that - as a client - you do not *need* to 
care about implementation details, not that you can not get at it. And 
while data hiding is indeed a possible mean to enforce some kind of 
encapsulation, it's not quite the same thing.