Why does python not have a mechanism for data hiding?

[Carl Banks]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 6:39 pm, "Russ P." <Russ.Paie...@g mail.comwrote:

On Jun 2, 3:04 pm, Carl Banks <pavlovevide... @gmail.comwrote :
>
>
>

On Jun 2, 4:50 pm, "Russ P." <Russ.Paie...@g mail.comwrote:

>

On Jun 2, 6:41 am, Carl Banks <pavlovevide... @gmail.comwrote :

>

You are not realizing that only useful(**) thing about data hiding is
that some code has access to the data, other code does not. If you
"hide" data equally from everyone it's just a useless spelling change.

>

I think you're missing the point.

>

Well that's nice: you're accusing me of missing the point after having
quoted something I wrote as if it represented by own views, even
though I footnoted it and said I was only doing it for the sake of
argument. Perhaps, outside this discussion, I am totally getting "the
point".

>

I can't tell, though, because I read your post twice and I have no
idea what you consider "the point" to be.
Best as I can tell you are claiming that data hiding isn't important,
but then you go on to imply Python is blemished because it doesn't
hide data. It really makes no sense: perhaps you can help us out by
giving us an example of something that illustrates what you're saying?

>
I think I made my point abundantly clear. I said that rigorously
denied access to encapsulated data is not important, but a clear
specification of what is intended for the client and what is intended
for internal use *is* important. And an ugly naming convention for
variable and function names is not the best way to do it.

Well let me tell you what's confusing me here: I can't figure out, if
this is your standpoint, what issue you could have had with what I
said. What specifically did you disagree with? What did I say that
was wrong? It seems like we are more in agreement than not.

I suggest you ask yourself why C++, Java, Ada, and probably most other
"object-oriented" languages, have encapsulation or "data hiding." And
no, I am not claiming that *every* application written in Python needs
it, but certainly *some* could benefit from it.

I know what it's there for, chief. That's exactly what I was saying
to Antoon, and you took issue with it and claimed I was missing the
point. What gives?


Carl Banks

[Russ P.]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 4:17 pm, Carl Banks <pavlovevide... @gmail.comwrote :

On Jun 2, 6:39 pm, "Russ P." <Russ.Paie...@g mail.comwrote:
>
>
>

On Jun 2, 3:04 pm, Carl Banks <pavlovevide... @gmail.comwrote :

>

On Jun 2, 4:50 pm, "Russ P." <Russ.Paie...@g mail.comwrote:

>

On Jun 2, 6:41 am, Carl Banks <pavlovevide... @gmail.comwrote :

>

You are not realizing that only useful(**) thing about data hiding is
that some code has access to the data, other code does not. If you
"hide" data equally from everyone it's just a useless spelling change.

>

I think you're missing the point.

>

Well that's nice: you're accusing me of missing the point after having
quoted something I wrote as if it represented by own views, even
though I footnoted it and said I was only doing it for the sake of
argument. Perhaps, outside this discussion, I am totally getting "the
point".

>

I can't tell, though, because I read your post twice and I have no
idea what you consider "the point" to be.
Best as I can tell you are claiming that data hiding isn't important,
but then you go on to imply Python is blemished because it doesn't
hide data. It really makes no sense: perhaps you can help us out by
giving us an example of something that illustrates what you're saying?

>

I think I made my point abundantly clear. I said that rigorously
denied access to encapsulated data is not important, but a clear
specification of what is intended for the client and what is intended
for internal use *is* important. And an ugly naming convention for
variable and function names is not the best way to do it.

>
Well let me tell you what's confusing me here: I can't figure out, if
this is your standpoint, what issue you could have had with what I
said. What specifically did you disagree with? What did I say that
was wrong? It seems like we are more in agreement than not.
>

I suggest you ask yourself why C++, Java, Ada, and probably most other
"object-oriented" languages, have encapsulation or "data hiding." And
no, I am not claiming that *every* application written in Python needs
it, but certainly *some* could benefit from it.

>
I know what it's there for, chief. That's exactly what I was saying
to Antoon, and you took issue with it and claimed I was missing the
point. What gives?
>
Carl Banks

I thought you were saying that encapsulation or so-called "data
hiding" is worthless. If I misunderstood you, then I apologize. I
don't have time to go back and sort it all out.

Here's what I think Python should have. I think it should have a
keyword, something like "priv," to identify data or functions as
"private." As I said earlier, "private" for class data or functions
("methods") could be implemented like "protected" in C++. That means
that derived classes would have access to it, but clients of the class
would not. If the client really needs or wants access, he could be
given a sort of "back door" access similar to the current Python rule
regarding double leading underscores. Thus, the client would have
access, but he would know very well that he is using something that
the original designer did not intend for him to use.

It's just a suggestion. I'm not a language expert, and I realize that
I could be missing something important.

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. 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).

[Paul Rubin]

Re: Why does python not have a mechanism for data hiding?

"Russ P." <Russ.Paielli@g mail.comwrites:

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.

This is bogus about 95% of the time though. For the cases where it is
really desired, I think it's best to require the target class to be
enable it specifically somehow, maybe by inheriting from a special
superclass. That could let the compiler statically resolve member
lookups the rest of the time.

[Carl Banks]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 7:41 pm, "Russ P." <Russ.Paie...@g mail.comwrote:

I thought you were saying that encapsulation or so-called "data
hiding" is worthless. If I misunderstood you, then I apologize. I
don't have time to go back and sort it all out.

No, not at all. I was suggesting that Antoon's example of data hiding
wasn't useful because it didn't really hide data: it was merely a
spelling change.

(I'm not, mind you, saying that it's ordinarily a good trade-off to
encapsulate data, but I do get the point of it.)

Here's what I think Python should have. I think it should have a
keyword, something like "priv," to identify data or functions as
"private." As I said earlier, "private" for class data or functions
("methods") could be implemented like "protected" in C++. That means
that derived classes would have access to it, but clients of the class
would not. If the client really needs or wants access, he could be
given a sort of "back door" access similar to the current Python rule
regarding double leading underscores. Thus, the client would have
access, but he would know very well that he is using something that
the original designer did not intend for him to use.

Reasonable enough. I've always thought C++ should have a
private_cast.


Carl Banks

[Carl Banks]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 10:14 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:

On 2008-06-02, Carl Banks <pavlovevide... @gmail.comwrote :
>
>
>

On Jun 2, 9:07 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:

On 2008-06-02, Carl Banks <pavlovevide... @gmail.comwrote :

>

On Jun 2, 6:40 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:
On 2008-06-02, Carl Banks <pavlovevide... @gmail.comwrote :

>

On Jun 2, 5:38 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:
If you really need it, you can do data hiding in python. It just
requires a bit more work.

>

----------------------------- Hide.py ---------------------------------
class Rec(object):
def __init__(__, **kwargs):
for key,value in kwargs.items():
setattr(__, key, value)

>

def __getitem__(sel f, key):
return getattr(self, key)

>

def __setitem__ (self, key, val):
setattr(self, key, val)

>

class Foo(object):

>

def __init__(self):

>

hidden = Rec(x=0, y=0)

>

def SetX(val):
hidden.x = val

>

def SetY(val):
hidden.y = val

>

def GetX():
return hidden.x

>

def GetY():
return hidden.y

>

self.SetX = SetX
self.SetY = SetY
self.GetX = GetX
self.GetY = GetY

>

In other words, it's a useless no-op.

>

In fact, I'd say this is even worse than useless. Creating accessor
functions is a sort of blessing for external use. Knowing that there
are accessor functions is likely to cause a user to show even less
restraint.

>

I think you completed missed the point.

>

I'm not sure I missed the point so much as I failed to read your mind.

>

Fine with me, it is just the other side of the coin.

>

This is just a proof of concept thing. In a real example there would
of course no Set en Get methods but just methods that in the course
of their execution would access or update the hidden attributes

>

Fair enough, but I don't see anything in your example that suggests a
way to discriminate between access from within the class and access
from outside the class, which is the crucial aspect of data hiding.

>

The fact is that hidden and its attributes are not accessible from
outside the instance. They are only accessible to the local functions
of __init__. By binding those local functions as atributes to the
instance, hidden can be modified by what for all practical purposes
looks like a method call, but really is a closure call.

>

You haven't hidden the data at all, all you've done is to change the
means of accessing it. What difference does it make whether I write
foo.getX() or foo.x? Everyone in the world still has full access to
the data.

>
Can't you look beyond the specific example? The GetX is just an example.
Any local function of __init__ has access to hidden and its attributes
and could manipulate them, even if the class wouldn't define getters
and setters.

Ok. You could have made the proof-of-concept-ness of your example
more clear by not, you know, binding those local functions to globally
accessable names, thus thwarting your own concept.

But still, we all knew functions could do that. How could you make
data private to a group of functions (like, say, methods of a class,
or all functions in a module). It seems you'd have to define all
functions in the the same function scope, instead of where they'd more
naturally be defined (in the class or module scope). Unwieldy to say
the least, but doable, I suppose.


Carl Banks

[alex23]

Re: Why does python not have a mechanism for data hiding?

On Jun 3, 9:41 am, "Russ P." <Russ.Paie...@g mail.comwrote:

Here's what I think Python should have. I think it should have a
keyword, something like "priv," to identify data or functions as
"private."

As I stated earlier in this thread, if you want a public interface and
a private implementation, rather than adding another language feature
why not just separate them into two classes? This is exactly what the
Bridge pattern provides and would clearly denote your intention in the
code.

[Russ P.]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 6:21 pm, alex23 <wuwe...@gmail. comwrote:

On Jun 3, 9:41 am, "Russ P." <Russ.Paie...@g mail.comwrote:
>

Here's what I think Python should have. I think it should have a
keyword, something like "priv," to identify data or functions as
"private."

>
As I stated earlier in this thread, if you want a public interface and
a private implementation, rather than adding another language feature
why not just separate them into two classes? This is exactly what the
Bridge pattern provides and would clearly denote your intention in the
code.

Yes, that looks interesting, but I think it has a couple of drawbacks.
First, it requires another completely separate class for the
"implementation " (although perhaps that could be a nested class).
Secondly, I think it essentially just adds a sort of inner namespace
through which the "private" data is accessed. That might be a good
idea, but I don't think it's quite the same as encapsulation.

[Russ P.]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 5:11 pm, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

"Russ P." <Russ.Paie...@g mail.comwrites:

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.

>
This is bogus about 95% of the time though. For the cases where it is
really desired, I think it's best to require the target class to be
enable it specifically somehow, maybe by inheriting from a special
superclass. That could let the compiler statically resolve member
lookups the rest of the time.

It did seem a bit odd to me when I realized that you can add data
members (or even a "methods") to a class from completely outside the
class definition. That can be risky, of course, and as you suggest,
perhaps it shouldn't even be allowed by default.

I usually find that it's safer to initialize in the constructor all
(or nearly all) of the data members that will be needed in a class. If
I need a list that will be populated later, for example, I reserve the
name with an empty list in the constructor. Then, if for some reason
the list gets accessed before it is populated, I don't get an
exception.

[alex23]

Re: Why does python not have a mechanism for data hiding?

On Jun 3, 2:11 pm, "Russ P." <Russ.Paie...@g mail.comwrote:

Yes, that looks interesting, but I think it has a couple of drawbacks.
First, it requires another completely separate class for the
"implementation " (although perhaps that could be a nested class).

That's hardly an enormous overhead, and it does clearly separate the
interface you want your "users" to have from the implementation. Even
better, since you seem so concerned with others meddling with your
implementation directly, they could provide their own quite easily if
they so choose.

Secondly, I think it essentially just adds a sort of inner namespace
through which the "private" data is accessed. That might be a good
idea, but I don't think it's quite the same as encapsulation.

It's a clear separation of concerns, check. It removes the underscored
methods you find so aesthetically offensive, check. I have absolutely
no idea what _you_ mean by "encapsulation" .

Then again, I have no issue with the current convention and personally
find the idea of adding a "private" keyword makes as much sense as
being able to syntactically define "model", "view" and "controller "
methods.

[Russ P.]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 10:23 pm, alex23 <wuwe...@gmail. comwrote:

On Jun 3, 2:11 pm, "Russ P." <Russ.Paie...@g mail.comwrote:
>

Yes, that looks interesting, but I think it has a couple of drawbacks.
First, it requires another completely separate class for the
"implementation " (although perhaps that could be a nested class).

>
That's hardly an enormous overhead, and it does clearly separate the
interface you want your "users" to have from the implementation. Even
better, since you seem so concerned with others meddling with your
implementation directly, they could provide their own quite easily if
they so choose.
>

Secondly, I think it essentially just adds a sort of inner namespace
through which the "private" data is accessed. That might be a good
idea, but I don't think it's quite the same as encapsulation.

>
It's a clear separation of concerns, check. It removes the underscored
methods you find so aesthetically offensive, check. I have absolutely
no idea what _you_ mean by "encapsulation" .
>
Then again, I have no issue with the current convention and personally
find the idea of adding a "private" keyword makes as much sense as
being able to syntactically define "model", "view" and "controller "
methods.

I'm not saying your bridge pattern is no good. It is a form of
encapsulation, I suppose, but it is cumbersome. With my suggested
"priv" keyword, you just use it once (per data member or function) and
you never need to use it again. With your approach, not only do you
need twice the number of classes, you need to use the longer names
every time you access the data.

[Russ P.]

Re: Why does python not have a mechanism for data hiding?

On Jun 2, 10:23 pm, alex23 <wuwe...@gmail. comwrote:

Then again, I have no issue with the current convention and personally
find the idea of adding a "private" keyword makes as much sense as
being able to syntactically define "model", "view" and "controller "
methods.

Well, the designers of C++, Java, and Ada, to name just three very
popular languages (well, two) seem to think it makes sense. But maybe
you know more than they know.

[alex23]

Re: Why does python not have a mechanism for data hiding?

On Jun 3, 3:42 pm, "Russ P." <Russ.Paie...@g mail.comwrote:

Well, the designers of C++, Java, and Ada, to name just three very
popular languages (well, two) seem to think it makes sense. But maybe
you know more than they know.

You do realise the same argument could be made about you and the
designers of Python, right?

But regardless, an argument from authority is a sure sign that this
isn't worth continued debate.

Good luck with the PEP.

[Antoon Pardon]

Re: Why does python not have a mechanism for data hiding?

On 2008-06-03, Carl Banks <pavlovevidence @gmail.comwrote :

On Jun 2, 10:14 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:

>On 2008-06-02, Carl Banks <pavlovevide... @gmail.comwrote :

>Can't you look beyond the specific example? The GetX is just an example.
>Any local function of __init__ has access to hidden and its attributes
>and could manipulate them, even if the class wouldn't define getters
>and setters.

>
Ok. You could have made the proof-of-concept-ness of your example
more clear by not, you know, binding those local functions to globally
accessable names, thus thwarting your own concept.
>
But still, we all knew functions could do that.

Well maybe you all knew that, yet while I read the thread, I saw
noone mentioning this possibility to get what the OP seemed to
want. I also did't see other posibilities. Your idea as an alternative
only came as a reaction to my idea.

I know my idea as presented was cumbersome. Maybe it can be worked out
more, maybe with the help of decorators to be less cumbersome.

I also know it can be circumvented in CPython.


Yet I think is was usefull to explore what is already possible in Python
instead of just argueing about whether people need it or not


I always find it odd when the "you don't need it" argument is used.
Of course that is correct, put python has acquired a lot of things
that were originnally labeled "you don't need it". So why people
still use it against introducing something, is something I don't
entirely understand.

--
Antoon Pardon

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

Re: Why does python not have a mechanism for data hiding?

On Mon, Jun 2, 2008 at 10:50 PM, Russ P. <Russ.Paielli@g mail.comwrote:

On Jun 2, 6:41 am, Carl Banks <pavlovevide... @gmail.comwrote :
>

>You are not realizing that only useful(**) thing about data hiding is
>that some code has access to the data, other code does not. If you
>"hide" data equally from everyone it's just a useless spelling change.

>
I think you're missing the point.
>
As I see it, the primary value of data hiding is that it provides
useful information on which data and methods are intended for the
client and which are intended for internal use. It's like putting a
front panel on a TV set with the main controls intended for the
viewer.

Here's my two cents. First of all, a TV is a bad analogy compared to
reusable software libraries. Really bad analogy. A TV is a horribly
complicated device which has to be dumbed down because otherwise it
would be to hard to use for ordinary people.

A software developers relation to a third party library is more
similar to a TV repair man trying to repair a TV than to a random
person watching TV. For a repair man, the front panel is just useless
and in the way.

Oh, and to continue on the TV analogy, one of the reason why a TV is
complicated is because its interface is totally different from its
implementation. Channels are just a bad abstraction for tuning the
receiver to different frequencies and for switching inputs. Merely
using a TV doesn't teach you anything about how it actually works.

KISS: Keep It Simple Stupid. And it is always simpler to not implement
the gunk needed for data hiding than to do it. By keeping things
simple you keep your code easy to implement, easy to understand and
easy to reuse.

Data hiding sacrifices implementation simplicity supposedly to make
the interface simpler and to keep backwards compatibility. It allows
you to change implementation details without affecting the
interface. But do you really want to do that? Consider this silly Java
example:

class Foo {
private int bar;
public int getBar() {
return bar;
}
};

Then for some reason you decide that hm, "bar" is not a good attribute
name so you change it to "babar". And you can do that without changing
the public interface! Woho! So now you have a public getter named
"getBar" that returns an attribute named "babar". That's in reality
just bad and whoever is maintaining the implementation is going to be
annoyed that the getters name doesn't match the attribute name.

What would have happened without data hiding? Renaming the public
attribute "bar" to "babar" probably cause some grief for someone
reusing your library, but you would keep your implementation pure.

What about semantic changes? Data hiding doesn't protect you against
that, so you'll have to change your interface anyway. The interface
for a car hasn't changed much in the last 100 years, but the
implementation has. How easy is it to repair a car nowadays compared
to 30 years ago?

And data hiding as a documentation aid is just a sham. "These methods
are public so you can call them, these aren't so hands off!" A reuser
of your library *will* want to know what happens on the inside, by
trying to make stuff impossible to reach you are just making that kind
of information much harder to come by.

The better method is to just write proper docstrings that tell the
user what the methods do and when they can be called.

Another good way to see how useless data hiding is, is to try and unit
test a very encapsulated library. You'll see that it is almost
impossible to write good unit tests unless you publicly export
almost everything in the code. At which point you come to realize that
all the data hiding was for naught.


--
mvh Björn

[Lie]

Re: Why does python not have a mechanism for data hiding?

On May 24, 9:14 pm, Fuzzyman <fuzzy...@gmail .comwrote:

On May 24, 2:58 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:
>

Sh4wn <luckyluk...@gm ail.comwrites:

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?

>
Actually, 'data hiding', although vastly overused by the static crowd
can be a reasonable thing to want.
>
For example, at Resolver Systems we expose the spreadsheet object
model to our users. It hasa public, documented, API - plus a host of
undocumented internally used methods.
>
We would really *much* rather hide these, because anything our
customers start using (whether documented or not) we will probably
have to continue supporting and maintaining.
>
The 'we told you not to use that' approach, when applied to paying
customers doesn't really work... all they see is that you broke their
spreadsheet code by changing your API.
>
You can make members truly private by proxying, but it is a bit
ungainly.

Then don't document it, or separate internal documentation (which is
never to pass through the wall) and public documentation (which your
users use). Nobody would (apart from your dev team and anyone told by
your dev team, which means you may fire the person for "lack of
discipline") know that there is such a thing and in consequence
wouldn't use it.

Don't tell your user not to use something, just don't tell them that
it exists and they won't use it.