On Jun 6, 8:25 am, Bruno Desthuilliers <bruno. [EMAIL PROTECTED]> wrote:
> >>> I also realize, by the way, that Python allows a client of a class to > >>> define a new class member from completely outside the class > >>> definition. Obviously, that cannot be declared private. > >> Why so ? > > > Why should the client of a class not be able to declare a *private* > > member of the class? You're kidding, right? > > I'm dead serious. I often add implementation attributes to either a > class or an instance. These *are* implementation parts, not API. If a client accesses a data member of a class, then by definition that member is not really private, so letting the client create a new data member and declare it as private seems a bit silly to me. Actually, just letting the client create the new data member, private or not, seems like a bit of a stretch to me, but I'll leave that be. > > For the record, I have made it abundantly clear that I don't think > > Python should not have as rigorous an encapsulation regime as C++ or > > Java. The worst that could happen with my proposition is that you > > would need to use a "mangled" name to access private data or methods. > > That's already the case - when you use __name_mangling. And if there's > no effective access restriction, then what the point of having this > 'priv' keyword ? > > > But you will be using the name many times, you can reassign your own > > name, of course, so the mangled name need not appear more than once > > where it is needed. > > Once again, I just don't see the point. Either you want effective access > restriction in Python, or you don't. And if you don't, what would this > 'priv' keyword be useful to ? In the end, I suppose it boils down to aesthetics and personal preference. The leading-underscore convention bothers me for two reasons: (1) like the OP, I don't like the way it makes my code look, and (2) it is a signal to a person reading the code, but it has no actual effect in the interpreter. I think the concept of private data and methods is important enough to be implemented with more than just a tacky naming convention. That is why I suggested the "priv" keyword. At the same time, I realize that people will occasionally be frustrated if they are rigorously denied access to all private data, which is why I suggested an "indirect" method of access through mangled names. You can argue that such indirect access defeats the whole idea of private data, but at least it alerts the client to the fact that he (or she or it) is accessing private data -- and it does so without using Hungarian notation. I would let the "priv" keyword also be used for data or functions at file scope. It just seems logical to me. Again, some name mangling convention could be concocted for those who think they really need access. Actually, the whole objection to denied access baffles me a bit. Does anyone object to not having access from outside a function to local variables within the function? I doubt it. The other thing is that the vast majority of Python software, I would guess, is provided with source code. How many Python applications or libraries are provided without source code? If you have the source code, you can obviously just delete the "priv" keyword anywhere or everywhere it appears. And if you have a major client who insists on access to all the internals, just delete all occurrences of "priv" before you ship the code (or don't use it to start with). -- http://mail.python.org/mailman/listinfo/python-list
