Bengt Richter wrote: > > I decided to read this thread today, and I still don't know exactly > what your requirements are for "private" whatevers.
No name collision in subclassing. Notice that even if you use self._x = 3 in a parent class, it can be overriden in a sub-sub-class accidentally. > Or maybe, what are your real requirements? > ;-) No need for this type of joke. For people coming from Java/C++ camp, (especially Java camp,) they think they've got something good with the private class variable, and they think the lack of an exact equivalent in Python means Python is lesser in this regard. The thing is, there are two sides to every coin. Features surely can be viewed as "goodies", or they can be viewed as "handcuffs". Python's lack of Java-style "private" surely has its drawback: name collisions can happen. But, that's just one side. Name collisions are allowed in many dynamic languages, where you can override the default system behavior (in some languages, you can override/intercept the assignment operator "=", or even the "if" statement and the "while" loop.) Sure, in these very dynamic languages you can ACCIDENTALLY override the default system behavior. How many Python programmers have once upon a time done stupid things like: list = 3 , without realizing that list() is a Python function? This type of accidental overriding DOES happen. Similarly, in large and complicated Python projects, name collision (even for "self._x" type of private members) CAN happen, and I am sure it has happened for some people. Now the question is: for average people and average project, how often does this type of error happen? If people really cool down their heads and don't talk emotionally, and base on their real experience throughout the years, the truth is that this type of error just doesn't happen that often. And even if it does happen, the error is usually fatal enough to be detected. OK, I have said that not having Java-style "private" has one downside in Python. But what's the upside? Not having "private" in Python closes one door, but opens another door. The upside is exactly the same as the fact that you can override the "list()" function in Python. Python is dynamic language. Like others have pointed out, you can not even be sure about the variable content of a class/object during runtime. In Java, you cannot override your private members during runtime. In Python, if you have a private variable: self._x = 3 and you, for curiosity reasons and DURING runtime (after the program is already up and running) want to know the exact moment the self._x variable is accessed (say, print out the local time), or print out the calling stack frames, you can do it. And I mean the program is running. In Java, you would have to stop the program, re-write/re-implement changes, re-compile, re-start the program, etc. etc. The thing is, Python allows you to do runtime dynamic programming much more easily than Java/C++. This type of dynamic and metaprogramming are kind of unthinkable in the C++/Java world. Sure, these are advanced programming features that not everybody uses, but Python leaves the door open for those who want to take advantage of these powerful features. The fact that you can override Python's "list()" function can be either viewed as pro or con. The fact that you can override member variables can also be viewed as pro or con. Would any Python programmer trade the benefits of a highly dynamic language with an unessential feature like Java-style "private" data members? My guess is not. --------------- What do I say Java-style "private" is unessential? If your Python class/object needs a real Java-style private working namespace, you have to ask yourself: do the private variables REALLY belong to the class? In my opinion, the answer is: NO. Whenever you have Java-style private variables (i.e, non-temporary variables that need to persist from one method call to the next time the class node is accessed), those variables/features may be better described as another object, separate from your main class hierarchy. Why not move them into a foreign worker class/object instead, and let that foreign worker object hold those private names, and separate them from the main class hierarchy? (In Microsoft's jargon: why not use "containment" instead of "aggregation"?) That is, the moment you need Java-style private variables, I think you might as well create another class to hold those names and functionalities, since they do not belong to the core functionality of the main class hierarchy. Whatever inside the core functionality of the main class, should perhaps be inheritable, sharable and modifiable. If you use containment instead of aggregation, the chance for name collision reduces dramatically. And in my opinion, it's the Pythonic way of dealing with the "private" problem: move things that don't belong to this object to some other object, and be happy again. -- http://mail.python.org/mailman/listinfo/python-list
