is python Object oriented??
steven at REMOVE.THIS.cybersource.com.au
Tue Feb 3 09:45:23 CET 2009
On Tue, 03 Feb 2009 03:48:58 +0000, Rhodri James wrote:
> On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <Russ.Paielli at gmail.com>
>> Here we go again. If you have access to the source code (as you nearly
>> always do with Python code), then "breaking the language-enforced data
>> hiding" is a trivial matter of deleting the word "private" (or
> If it's that trivial to defeat something that its proponents appear to
> want to be close to an iron-clad guarantee, what on earth is the point
> of using "private" in the first place?
Well, that is a good question.
Since it is even more trivial to defeat Python's private-by-convention
data hiding, why even bother? Just make everything public. What on earth
is the point of prefixing an attribute with an underscore?
I think this debate has a lot to do with people's attitudes towards "No
User Serviceable Parts". Some people are comfortable using black-boxes,
and if (enforced) data hiding makes it easier for others to build safe,
efficient black-boxes, then they're willing to give up that a little bit
of flexibility/freedom for the benefit of safe, efficient black-boxes.
Others prefer white-boxes, and are willing to give up some safety and
efficiency, and live with increased risk and lower performance, just in
case some day they might want to open up the white-box and replace the
widget with a gadget.
Some of us consider that a black-box sealed with regular Phillips head
screws is still be an effective black-box. It's not hard to find a screw
driver and open the box, but it's still an effective barrier against
casual and accidental tinkering while allowing deliberate tinkering.
Others take the attitude that anything short of resistance to oxy torches
and diamond-tipped drills might as well be in a paper bag, and therefore
there's no point to black-boxes at all.
I find this extreme position is rather incoherent. If I may paraphrase
the argument as I see it:
"Enforced data hiding is useless, because it is utterly trivial to bypass
it, AND it's wicked, because it makes it unbelievably painful and
difficult to bypass it when you need to."
If it is trivial to bypass, surely it can't be that painful to bypass?
Another extreme position is that enforced data hiding is useless, that
there is *never* any need for it *at all*, and therefore Python doesn't
need it, there's no reason except stupid PHB's belief in cargo-cult
coding why Python couldn't be used for controlling nuclear reactors or
the Space Shuttle. There's been some claims remarkably close to that in
this or the previous thread. I trust that nobody really believes this
extreme position -- it's not that far off claiming that procedures and
functions are pointless and stupid because we have GOTO.
(The restrictions on GOTOs is analogous to enforced data hiding. We give
up the freedom and flexibility to jump into the middle of arbitrary
pieces of code in order to write safer and more maintainable code.)
But as I wrote once before, it is very liberating to program in Python,
and put responsibility for dealing with errors onto the caller. Let them
call your methods with invalid arguments, let them mess with your
internals, if it breaks, it's their responsibility!
Except when it isn't.
And that's when I'd like to be able to lock my classes down and enforce
data hiding. Not all the time, because I do like white-boxes, but
sometimes a black-box is the right choice, or the necessary choice, and
if that makes development harder, then that's a cost I'm willing to pay.
If I'm not willing to pay it, then I'll leave it as a nice, open,
transparent white-box with easily messed-with internals and let the
caller deal with the consequences of messing with the internals.
Whether you agree with that choice or not is irrelevant. *My* code, *my*
choice: it's my decision to write code as a black-box or a white-box,
just like it's my choice to use a BSD license or the GPL or a closed-
source proprietary license, or to make the class mutable or immutable.
If other people don't like my choices, well, you have lots of options:
you can sub-class, you can delegate, you can use somebody else's class,
you can write your own class, you can do without, you can fork the source
code, you can make do with it the way it is, or you can complain to the
Salvation Army about how I'm ruining your programming experience by
being too strict/not strict enough.
I love Python, and I'm greedy and want it all: I want a dynamic, easy-to-
use language *and* a compiler that can protect me from myself and bad
data. I'm envious of Haskell's type-inference. I want the option to have
the compiler warn me when some function is messing with my classes'
internals as soon as I hit Enter, and not to have to remember to run some
I'm not going to *demand* the choice of white-box or black-box classes. I
don't have the right to demand anything. But I can ask, I can try to make
my case (to those who will listen), and I refuse to be brow-beaten by
those who think Python is Just About Perfect Just The Way It Is into
feeling *ashamed* for wanting that choice.
 They give a damn.
More information about the Python-list