Why does python not have a mechanism for data hiding?

[Antoon Pardon]

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.

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.

 

[Carl Banks]

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



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.

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.


** - Usefulness is questionable in most cases, but we assume it is
here for the sake of argument.


Carl Banks

 

[Antoon Pardon]

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.

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 already explained this. The code is a proof of concept. I agree that
the example itself doesn't do anything usefull, that doesn't mean that
the concept it is trying to illustrate is useless too.


Your metaclass can be used to make attributes private. Your metaclass
doesn't stop doing that because someone makes a class with a getter
and a setter for those private attributes. The same goes for my example.
The closure makes a variable inaccessable to the outside. That doesn't
change because I defined a getter and a setter for that closure
variable.

 

[Russ P.]

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.

People seem to be preoccupied with whether or not the back panel of
the TV is locked, but that is not the main issue. Sure, you probably
want to make the back panel removable, but you don't want the viewer
opening it up to change the channel, and you certainly don't want to
put all the internal adjustments for factory technicians together with
the controls for the end user.

As far as I am concerned, the current Python method of using
underscores to distinguish between internal and external methods and
data is an ugly hack that goes completely against the elegance of the
language in other areas. It is like a TV set with no back cover and
the volume and channel controls intermingled with the factory
controls. The underscores are just an afterthought like a red dot or
something used to tell the TV viewer what to fiddle with.

Python is a very nice language overall, but as far as I am concerned
the underscore convention is a blemish. I just wish people wouldn't
get so infatuated with the language that they cannot see the obvious
staring them in the face.

 

[Carl Banks]

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?


(FWIW, my actual view on the matter is I don't give a lick about data
hiding or marking internals.)

Carl Banks

 

[Diez B. Roggisch]

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?


(FWIW, my actual view on the matter is I don't give a lick about data
hiding or marking internals.)

Do yourself a favor and google antoon's previous posts in this group. He
sure is a clever guy & I wouldn't call him a troll - but a bit trollish..

Diez

 

[Russ P.]

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.

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.

(FWIW, my actual view on the matter is I don't give a lick about data
hiding or marking internals.)

What kind of programming do you do?

 

[Carl Banks]

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

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 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]

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]

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]

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]

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

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

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]

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

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.


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

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]

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]

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.