Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Russ P. a écrit :
> On Jun 4, 4:29 am, NickC <ncogh... at gmail.com> wrote:
>> On Jun 4, 4:09 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
>>
>>> What is it about leading underscores that bothers me? To me, they are
>>> like a small pebble in your shoe while you are on a hike. Yes, you can
>>> live with it, and it does no harm, but you still want to get rid of it.
>> With leading underscores, you can see *at the point of dereference*
>> that the code is accessing private data. With a "this is private"
>> keyword you have no idea whether you're accessing private or public
>> data, because the two namespaces get conflated together.
> 
> That is true. But with the "priv" keyword you'll discover quickly
> enough that you are trying to access private data (as soon as you run
> the program).

With the current convention, you don't even have to run the program - as 
soon as you *type* the name, you know you're accessing implementation stuff.

> And even if a "priv" keyword is added, you are still
> free to use the leading underscore convention if you wish.

What does this "priv keyword" buy you then ? Seriously ?

> The idea of being able to discern properties of an object by its name
> alone is something that is not normally done in programming in
> general. 

Want to talk about the hungarian notation that is everywhere in MS 
Windows code ?-) or about the so common C++ coding guideline that 
insists on prefixing "data members" with a m_ or a w_ ?-)

More seriously: yes, you usually try to convey something about some 
relevant properties of the object in the identifier. Like, you know, 
using plurals for collections. Or i, j as loop indices.

> Yes, of course you should choose identifiers to be
> descriptive of what they represent in the real world, but you don't
> use names like "intCount," "floatWeight," or "MyClassMyObject" would
> you? 

Nope.

> Why not?

Because the naming convention for variables is all_lower_with_underscores.

Also, because 'count' is likely enough to be an integer and 'weight' 
likely enough to be a float - and else another numeric. While 'counts' 
and 'weights' are likely enough to be collections (likely lists) of 
resp. integers and floats.