is python Object oriented??

[Steven D'Aprano]

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>
> wrote:
> 
>> 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
>> equivalent).
> 
> 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[1] 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 
third-party tool.

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.






[1] They give a damn.

-- 
Steven