>> >> You, sir, should be programming in some language other than Python. > > Why? - Python is object oriented, but I can write whole systems > without defining a single class. > By analogy, if data hiding is added to language, I could write a > whole system without hiding a single item. > Conversely, the lack of data hiding is perceived as a weakness, > and IMO harms the advocacy of the language -
This is an alarming statement. Advocacy should advocate the language-- it must not define the language. If a fundamental principle of the language harms the advocacy of the language: then the problem is not with the language but the advocacy. If you are going to advocate a thing: advocate that thing. Don't try to change that thing into what it is not so as to make your advocacy the end-goal. One of the reasons I love Python is because its practical first. It begins with its license, which some people argue allows companies to steal effort from its developers to use for their own purposes without contributing back. The Python license is about empowering people to accomplish things, to do things. It goes further. Guido and the core developers ask real questions: would this add a burden to practical use, or would it hinder another practical use? > This is proven > by your statement above, whereby you are driving a user away, > simply because the language, in one small aspect, does not > give him what he wants, and the tenor of this thread has been > very much: "That's how it is - like it or lump it", and no amount > of careful explanation of why people want the feature has cut > any ice - I'm missing the careful explanation. What I've heard is that the lack of enforced encapsulation is "a danger". What I've heard is that people want it because they've been told they should want it and believe that. Why? Part of my lack of understanding might be because people couldn't read my previous messages because my mail client's configuration accidentally got fubar'd and I was sending HTML mail instead of plain text. But my question remains: Why do you need forced encapsulation? There have been no "careful explanations" to answer that, in my mind. And thus my response is: the practical possibility of needing access vastly outweights the theoretical situation that might go bad if encapsulation wasn't there. Why? Because in any real situation, IMHO, *forced* encapsulation is pointless. If you are writing end-level code, you can achieve forced encapsulation by simply not playing with anyones privates. If you are in a corporate environment who has rules about accessing privates written by another team for valid reasons, your policy to not do so should be enough or your review process should pick it up. If you are in an open source environment accepting patches from various people, you should have a clear policy about the subject if you think breaking encapsulation is never acceptable and refuse the patches. Those who have commit access and violate encapsulation anyways against your projects policy are problems that you clearly need to deal with. The problem is not the language at that point, its the contributor. > It has all the time been countered with statements > about how the proponents of private attributes "don't need it", > (as if they are plain dumb), They don't need it. No one has shown a *real* reason why. The only reasons provided are "its a DANGER" that someone "MIGHT DO BAD". That's not a real reason. If its your project that someone is doing bad in, this is a situation which can be *clearly* specified in a projects policy and coding standards and can be *trivially* tested for with simple static analysis in nearly all cases. The problem is the person and not the code then. There's *countless* other ways that person can do bad if you're allowing them to commit blindly anything into your project. If its your projet which someone else is using, and accessing your internals that are clearly private and not documented: its not your problem if they stab themselves in the foot. On the contrary, why in the name of all that is holy, do you care if they manipulate your internals at their own risk, at their own cost, and achieve something positive for them? How in any way does this hurt you? > that an underscore convention is > "just as good", (It isn't), Why isn't it? > that you could crack it if you really > tried, (so what?), Exactly.. so what? WHY is the convention not enough? What REAL situation is there that the lack of *forced* encapsulation but policy based encapsulation not enough? > Surely if "we are all adults here" we have to accept that the > other man has as much right to get what he wants, as > anybody else, and that his reasons are as valid as those of > anybody else. Yes., We're all consenting adults. But if one adult decides to make rules that the other doesn't agree to, is that consenting adults, or is that rape? I apologize for the use of the term, but "consenting adults" has particular connotations that seem to apply very well here, in the context of that expression. Forced encapsulation allows one party to make absolute rules and hold absolute authority over another party. If you believe that encapsulation should never be broken: do not break it. If your organization, corporation or project believes that encapsulation should never be broken: specify that it must not be done. Your review process (you do have one, right?) will pick it up and you can very quickly deal with the situation. Encapsulation is a very, very good thing in general: but it is a question of *design* and not *implementation*. Python allows EVERYONE who wants encapsulation to HAVE it. Not forced encapsulation, but encapsulation. If you're producing a product in Python on your own simple policy and trivial review (even -automated- review; it is NOT hard to tell that "other._private" is not "self._private") provides encapsulation. If you're making a library for others to use, there is no valid reason for you to care if they screw with your internals. Really. I just don't get the problem. It seems to me that people who want this in Python will never be happy *in* Python. Its a very deep fundamental feature that Python exposes everything it can, even things that are potentially dangerous like sys._getframe. Recently on Python-dev(note: I only lurk) someone was working on a debugger and they were told in that situation it was OK to access a private member of sys to achieve an end: exposing that internal to general use just had no value. That's the Python Way. People can dig into things, classes, functions, and screw around in wild ways if they want to. That *is* what Python is. 95% of code by 95% of people won't ever go there, but its there. To remove it means its *not* Python. --S -- http://mail.python.org/mailman/listinfo/python-list
