On Feb 3, 1:14 am, David Cournapeau <courn...@gmail.com> wrote: > On Tue, Feb 3, 2009 at 2:37 PM, Russ P. <russ.paie...@gmail.com> wrote: > > On Feb 2, 7:48 pm, "Rhodri James" <rho...@wildebst.demon.co.uk> 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? > > >> -- > >> Rhodri James *-* Wildebeeste Herder to the Masses > > > If a library developer releases the source code of a library, any user > > can trivially "defeat" the access restrictions. But if a team of > > developers is checking in code for a project, the leader(s) of the > > project can insist that the access restrictions be respected to > > simplify the management of interfaces. The larger the team, the more > > useful that can be. That's why Java, C++, Ada, Scala, and other > > languages have a "private" keyword. > > I think a lof of this "discussion" is caused by different usages of > private. My understanding is that you think private is missing in > python because there is no clear different between a member which is > published (part of the API) and one which is not (e.g. whose behavior > may change between different revisions, even minor). I agree the > underscore is not an ideal solution - it is certainly not followed by > all python code out there (not even in python itself - see distutils > for example). > > But I think you are overstating the advantage of private for that > usage, at least for C++. In C++, if you have a public class in a > header: > > class Foo { > private: > int f; > > }; > > It means f is private (cannot be accessed outside Foo instances), but > it is declared in the public header. Actually, when people means this > kind of 'data-hiding', C++ does not bring anything to C itself - after > all, we have used FILE* for years and I have no idea about the FILE > structure.
Your lack of knowledge about it doesn't mean that it has somehow magically "private" members. The only reason that most of us don't know what a FILE is is that it's definition is implementation-defined (i.e., every compiler may define it differently). That doesn't have anything to do with private members. For example, on my system, <stdio.h> defines FILE as: struct _iobuf { char *_ptr; int _cnt; char *_base; int _flag; int _file; int _charbuf; int _bufsiz; char *_tmpfname; }; typedef struct _iobuf FILE; Given this information, nothing prevents me from writing things like: FILE* fp = fopen("file.txt", "r"); if (!fp) { /* do something */ } printf("fp->_cnt = %d\n", fp->cnt); printf("fp->_flag = %d\n", fp->_flag); printf("fp->_file = %d\n", fp->_file); fp->_flag = 0x20; // OOPS!! > Maybe I still lack experience, but I find neither _ prefixing nor > private/public/protected a satisfaying way to make clear what is > public API and what is not. In particular, if I have a python package > which does not use _ at all, shall I assume everything is public ? Pretty much, unless maybe the code documents what you're not supposed to access: class IOBuf: def __init__(self): self.ptr = "" # <- this is private! self.cnt = 0 # <- this is private! self.base = "" # <- this is private! self.flag = 0 # <- this is private! self.file = 0 # <- this is private! self.charbuf = 0 # <- this is private! self.bufsiz = 0 # <- this is private! self.tmpfname = "" # <- this is private! Nope, not a good idea either... -- http://mail.python.org/mailman/listinfo/python-list