On Tue, 03 Feb 2009 03:48:58 +0000, Rhodri James wrote: > On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <russ.paie...@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 -- http://mail.python.org/mailman/listinfo/python-list
