is python Object oriented??

[David Cournapeau]

On Wed, Feb 4, 2009 at 2:36 AM,  <thmpsn.m.k at gmail.com> wrote:
> On Feb 3, 1:14 am, David Cournapeau <courn... at gmail.com> wrote:
>> On Tue, Feb 3, 2009 at 2:37 PM, Russ P. <Russ.Paie... at gmail.com> wrote:
>> > On Feb 2, 7:48 pm, "Rhodri James" <rho... at wildebst.demon.co.uk> wrote:
>> >> On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <Russ.Paie... at 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;

Hm, I guess it depends on the implementation, but it is at least
possible in C to completely hide the structure, by declaring only a
pointer, and defining the structure outside any public header file.
Then, you cannot accidentally access any member - it would result in a
compiler error.

This method is also used in C++, that's the pimpl pattern. It is used
for various purposes (avoid long compilation times when changing some
private implementation, actual data hiding), but the underlying idea
is that you hide the implementation from the public headers. That's
used for example by QT, and many other C++ libraries.

This shows quite strongly the limitations of the whole private/public
business in C++.

>
> Pretty much, unless maybe the code documents what you're not supposed
> to access:

But that's my point: that's just not true for many packages I have
used - some packages do follow the _ convention, some don't. For
example, to take an example I am somewhat familiar with: distutils
does not follow this at all. There is no documentation, and it is
almost impossible to know what's the API from implementation details,
the interface is leaking everywhere. Now, distutils is an "old"
package, but my experience at least showed me that this is relatively
common.

There are some relatively well known packages which use a different
mechanism to clearly separate the intended API, without using the _
convention, or more exactly in supplement of it.

David