On Feb 3, 4:14 pm, "Rhodri James" <rho...@wildebst.demon.co.uk> wrote: > On Tue, 03 Feb 2009 05:37:57 -0000, 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? > > > 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. > > Indeed he can. He can even do that in Python; it just requires a little > self-discipline from the team, or a validation script on the code > repository if he really doesn't trust them. Not only can this be done > without forcing the rest of the world to play, it makes things a little > less daunting when those nice clean interfaces turn out to be > incomplete/too slow/not what you thought.
This has already been refuted several times on this thread alone, so I will not bother doing it again. -- http://mail.python.org/mailman/listinfo/python-list
