473,699 Members | 2,530 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Why does python not have a mechanism for data hiding?

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
Jun 27 '08 #1
162 10248
Sh4wn <lu*********@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
Jun 27 '08 #2
Ben Finney <bi************ ****@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
Jun 27 '08 #3
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
Jun 27 '08 #4
Fuzzyman <fu******@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...

Jun 27 '08 #5
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/
Jun 27 '08 #6
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.
Jun 27 '08 #7
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.

Jun 27 '08 #8

"Benjamin Kaplan" <be************ *@case.eduwrote in message
news:ec******** *************** *************** ****@mail.gmail .com...
| On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <fu******@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_'.

Jun 27 '08 #9
In article <52************ *************** *******@m36g200 0hse.googlegrou ps.com>,
Sh4wn <lu*********@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 (aa**@pythoncra ft.com) <* http://www.pythoncraft.com/

Need a book? Use your library!
Jun 27 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.