Why does python not have a mechanism for data hiding?

[Gabriel Genellina]

En Mon, 26 May 2008 17:02:21 -0300, Russ P. <Russ.Paielli at gmail.com>  
escribió:
> On May 26, 9:08 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> wrote:
>> En Mon, 26 May 2008 06:14:19 -0300, Paul Boddie <p... at boddie.org.uk>  
>> escribió:
>>> On May 26, 6:49 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
>>>> I am also bothered a bit by the seeming inconsistency of the rules for
>>>> the single underscore. When used at file scope, they make the variable
>>>> or function invisible outside the module, but when used at class
>>>> scope, the "underscored" variables or functions are still fully
>>>> visible. For those who claim that the client should be left to decide
>>>> what to use, why is the client prohibited from using underscored
>>>> variables at file scope?
>>
>> There is no rationale because this is not how it works... [snip  
>> explanation of how import works]
>
> Well, that's interesting, but it's not particularly relevant to the
> original point. By default, underscored variables at file scope are
> not made visible by importing the module in which they appear. But
> underscored member variables of a class *are* made visible to the
> client by default. That's seems at least slightly inconsistent to me.

To make things clear: _variables ARE visible when you import a module:

C:\TEMP>type module.py
_variable = 123

(invoke python)
py> import module
py> module._variable
123
py> dir(module)
['__builtins__', '__doc__', '__file__', '__name__', '_variable']
py>
py> from module import _variable
py> _variable
123

Only when you use "from module import *" _variable isn't imported.
(new python session):

py> from module import *
py> _variable
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
NameError: name '_variable' is not defined

That last form should not be used normally, except when playing with the  
interactive interpreter.

> The issue here, for me at least, is not whether the data or methods
> should be absolutely hidden from the client. I'm perfectly willing to
> say that the client should have a back door -- or even a side door --
> to get access to "private" data or methods.
>
> But I also believe that some standard way should be available in the
> language to tell the client (and readers of the code) which methods
> are *intended* for internal use only. And that method should be based
> on more than a naming convention. Why? Because (1) I don't like
> leading underscores in my identifiers, and (2) I think I should be
> free to choose my identifiers independently from their properties.
>
> Is this a major issue? No. Is it a significant issue. Yes, I think so.

Ok, that's what you'd like Python to be. Unfortunately your view appears  
not to be shared by the language developers.

> Here's another suggestion. Why not use "priv" as shorthand for
> "private"? Then,
>
> priv height = 24
>
> at file scope would make "height" invisible outside the module by
> default. And the same line in a class definition would give "height"
> the equivalent of "protected" status in C++.

Python data model is centered on namespaces, and it's hard to tell whether  
certain attribute is being accessed from "inside the class" or from  
"outside the class" in order to allow or deny access.
It's not like static languages where the whole class definition has a  
certain lexical scope and it can't be modified afterwards; the set of  
allowed attributes is fixed at compile time. In Python you can  
add/remove/alter attributes (including methods) dynamically. You can  
create classes without using the class statement. The same method may be  
shared by many unrelated classes. If you can devise a practical and  
efficient mechanism to determine access right in all those varying  
circumstances, please post it to the python-ideas list for further  
discussion. (In the meantime we'll continue to use a naming convention for  
us consenting adults.)

> I think "height" looks cleaner than "_height". And isn't clean code a
> fundamental aspect of Python?

I like the fact that the mere attribute name conveys useful information  
abut its intended usage. And I don't care about the _, it doesn't look  
ugly to me. But that's just my personal opinion.

-- 
Gabriel Genellina