Why does python not have a mechanism for data hiding?

[Sh4wn]

Hi,

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.

Python advertises himself as a full OOP language, but why does it miss
one of the basic principles of OOP? Will it ever be added to python?

Thanks in advance,
Lucas

[Ben Finney]

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

Sh4wn <luckyluke56@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?

In Python, the philosophy "we're all consenting adults here" applies.
You shouldn't pretend to know, at the time you write it, all the uses
to which your code will be put. Barriers such as enforced "private"
attributes will only cause resentment when people, despite your
anticipations, *need* to access them and are then forced to hack their
way around them.

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. This is a string
signal that the attribute is part of the implementation, not the
interface. The reader is then on notice that they should not rely on
that attribute; but they are not *prohibited* from using it if
necessary to their ends.

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?

Perhaps you're confusing the "encapsulat ion" and "abstractio n"
principles for enforced access restrictions; they're not.

Will it ever be added to python?

I hope not.

--
\ "Why was I with her? She reminds me of you. In fact, she |
`\ reminds me more of you than you do!" -- Groucho Marx |
_o__) |
Ben Finney

[Ben Finney]

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

Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:

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. This is a
string signal that the attribute is part of the implementation, not
the interface.

Quite apart from whether it's a string signal, I meant to write that
it's a *strong* signal.

--
\ "Some people, when confronted with a problem, think 'I know, |
`\ I'll use regular expressions'. Now they have two problems." |
_o__) —Jamie Zawinski, in alt.religion.em acs |
Ben Finney

[Fuzzyman]

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

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.

Michael Foord

http://www.ironpythoninaction.com/

>
In Python, the philosophy "we're all consenting adults here" applies.
You shouldn't pretend to know, at the time you write it, all the uses
to which your code will be put. Barriers such as enforced "private"
attributes will only cause resentment when people, despite your
anticipations, *need* to access them and are then forced to hack their
way around them.
>
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. This is a string
signal that the attribute is part of the implementation, not the
interface. The reader is then on notice that they should not rely on
that attribute; but they are not *prohibited* from using it if
necessary to their ends.
>

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?
>
Perhaps you're confusing the "encapsulat ion" and "abstractio n"
principles for enforced access restrictions; they're not.
>

Will it ever be added to python?

>
I hope not.
>
--
\ "Why was I with her? She reminds me of you. In fact, she |
`\ reminds me more of you than you do!" -- Groucho Marx |
_o__) |
Ben Finney

[Ville M. Vainio]

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

Fuzzyman <fuzzyman@gmail .comwrites:

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.

And the customer point of view is quite reasonable - they have a job
to do, and a limited timeframe; sometimes accessing privates directly
is much better than waiting for updates from vendor. Bad designs (as
far as choosing publics goes) happen.

Even if their softare breaks on upgrade, you can quite clearly point
out that they used an internal api - and they will keep on using the
old version until they solve the problem. Everybody wins.

Perhaps a lint-like validation tool would be optimal for this
problem...

[Fuzzyman]

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

On May 24, 4:56 pm, vivai...@gmail. com (Ville M. Vainio) wrote:

Fuzzyman <fuzzy...@gmail .comwrites:

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.

>
And the customer point of view is quite reasonable - they have a job
to do, and a limited timeframe; sometimes accessing privates directly
is much better than waiting for updates from vendor. Bad designs (as
far as choosing publics goes) happen.

They will use whatever they find, whether it is the best way to
achieve a goal or not. Once they start using it they will expect us to
maintain it - and us telling them it wasn't intended to be used by
them in the first place won't cut it.

>
Even if their softare breaks on upgrade, you can quite clearly point
out that they used an internal api - and they will keep on using the
old version until they solve the problem. Everybody wins.
>

Not if they are waiting for a fix or new feature in the upgrade - and
we can't refactor because they are relying on APIs that we want to
remove.

We very much lose.

Perhaps a lint-like validation tool would be optimal for this
problem...

So we can refuse to execute their code if they use private APIs?

Proxying so that we can really hide our internal APIs is a better
solution.

This hasn't happened to us yet (our application has only been in
commercial use since January), but it is one of the reasons that
Microsoft's COM APIs grew so wide and wild, and caused them very real
problems in trying to improve them. We are keen to avoid the same
situation.

Michael Foord

http://www.ironpythoninaction.com/

[Sh4wn]

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

On 24 mei, 15:58, 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?
>
In Python, the philosophy "we're all consenting adults here" applies.
You shouldn't pretend to know, at the time you write it, all the uses
to which your code will be put. Barriers such as enforced "private"
attributes will only cause resentment when people, despite your
anticipations, *need* to access them and are then forced to hack their
way around them.
>
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. This is a string
signal that the attribute is part of the implementation, not the
interface. The reader is then on notice that they should not rely on
that attribute; but they are not *prohibited* from using it if
necessary to their ends.
>

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?
>
Perhaps you're confusing the "encapsulat ion" and "abstractio n"
principles for enforced access restrictions; they're not.
>

Will it ever be added to python?

>
I hope not.
>
--
 \            "Why was I with her? She reminds me of you. Infact, she |
  `\             reminds me more of you than you do!"  -- Groucho Marx |
_o__)                                                                  |
Ben Finney

Well for me, it the ideal way to make sure it contains so 'wrong'
data. You can create getter/setters, and in some cases only a getter
and validate the value given by the user. Then you'll not have to
worry about the data in the rest of your class, which makes life a lot
easier IMO.

[Paddy]

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

On May 24, 3: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.

"We told you not to use it in the API Docs"
"Those names with leading undoerscores means _DO_NOT_USE_IT"
"THose methods whose docstrings say DO NOT USE EXTERNALLY"

And if they still use them, then they'd be problematic no matter what
language was used.

Customers ey?
Can't live without 'em...
.... Actually that's customers Sir!

:-)

- Paddy.

[Terry Reedy]

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


"Benjamin Kaplan" <benjamin.kapla n@case.eduwrote in message
news:ec96e13908 05241357i6e481e 3enf12b4d213e88 7008@mail.gmail .com...
| On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <fuzzyman@gmail .comwrote:
|| 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.

Python was not really written with 'difficult' customers in mind ;-)

One could largely hide private vars with a program that substituted random
names for single _ names, and removed the doc strings for functions,
classes, and methods with such names.

Such a program could even put such names in a separate module imported as
'_private_do_no t_use_'.

[Aahz]

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

In article <52ba2118-d095-48a6-8844-2ee4c2ec2be1@m3 6g2000hse.googl egroups.com>,
Sh4wn <luckyluke56@gm ail.comwrote:

>
>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.
>
>Python advertises himself as a full OOP language, but why does it miss
>one of the basic principles of OOP? Will it ever be added to python?

Not directly addressing your point except insofar as it appears that
your understanding of OOP may be limited:

"...some experts might say a C++ program is not object-oriented without
inheritance and virtual functions. As one of the early Smalltalk
implementors myself, I can say they are full of themselves." --zconcept
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

Need a book? Use your library!

[Ville M. Vainio]

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

Fuzzyman <fuzzyman@gmail .comwrites:

>Perhaps a lint-like validation tool would be optimal for this
>problem...

>
So we can refuse to execute their code if they use private APIs?

No, but it could complain and point out the exact offending lines,
pointing their development effort to right direction.

Proxying so that we can really hide our internal APIs is a better
solution.

How about pyprotocols and other interface packages?

Proxying is pretty workable too, and it easily makes sense that the
official API objects should be different from the logic executing
objects.

[Fuzzyman]

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

On May 25, 2:28 am, "Terry Reedy" <tjre...@udel.e duwrote:

"Benjamin Kaplan" <benjamin.kap.. .@case.eduwrote in message
>
news:ec96e13908 05241357i6e481e 3enf12b4d213e88 7008@mail.gmail .com...
| On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <fuzzy...@gmail .comwrote:
|| 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.
>
Python was not really written with 'difficult' customers in mind ;-)
>

True. It's extremely suited to what we do though.Minor difficulties
like this are vastly outweighed by advantages. The difficulties are
real though.

One could largely hide private vars with a program that substituted random
names for single _ names, and removed the doc strings for functions,
classes, and methods with such names.
>

We need to *use* those names to display the spreadsheet once the
calculation has finished (and their code has run).

Such a program could even put such names in a separate module imported as
'_private_do_no t_use_'.

Splitting more of the functionality out is probably part of the best
solution.

Michael Foord

http://www.ironpythoninaction.com/

[Ville M. Vainio]

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

Duncan Booth <duncan.booth@i nvalid.invalidw rites:

Or if you code in C++ and they *really* need to get at something you
made private they will still get at it. I've been there and done
that: 'private' in languages which have it is rarely an advantage
and frequently a pain.

Indeed. In C++, they recommend the "pimpl idiom" (private
implementation) , which actually has real advantages ;-)

[Fuzzyman]

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

On May 25, 9:47 am, vivai...@gmail. com (Ville M. Vainio) wrote:

Fuzzyman <fuzzy...@gmail .comwrites:

Perhaps a lint-like validation tool would be optimal for this
problem...

>

So we can refuse to execute their code if they use private APIs?

>
No, but it could complain and point out the exact offending lines,
pointing their development effort to right direction.
>

Proxying so that we can really hide our internal APIs is a better
solution.

>
How about pyprotocols and other interface packages?
>

We're using IronPython. I haven't looked at pyprotocols but I know the
Zope interface package is at least partly written in C. Our
spreadsheet object model is very 'performance sensitive', so that's a
consideration. We should definitely explore the prior art in this area
before we implement anything ourselves.

Thanks

Michael Foord

http://www.ironpythoninaction.com/

Proxying is pretty workable too, and it easily makes sense that the
official API objects should be different from the logic executing
objects.

[Joe P. Cool]

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

On 24 Mai, 15:58, 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?

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. This is obvious for real world things e.g.
your
TV. Nobody likes to open the rear cover to switch the channel. Similar
arguments apply to software objects. "data hiding" is a harsh name, I
would
call it "telling what matters". The need for this becomes
indispensable in
really big software packages like the Eclipse framework with approx.
100000
classes. If you cannot tell the difference between inside and outside
you
are lost.

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.

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.

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.

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? Please don't tell me that
encapsulation
does not mean "enforced restriction". If the language has no syntactic
support for encapsulation then it does not have encapsulation. Similar
argument applies to Java where programmers sometimes claim that Java
"has"
properties because of setCrap/getCrap.

__
Joe