is python Object oriented??

[thmpsn.m.k at gmail.com]

On Feb 3, 12:05 pm, David Cournapeau <courn... at gmail.com> wrote:
> On Wed, Feb 4, 2009 at 2:36 AM,  <thmpsn.... 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.

I've done that to implement ADTs (abstract data types, also known as
opaque types), but it's far from optimal, mainly because:

- The compiler doesn't know the size of the class/struct (since it
hasn't seen its definition), so you have to provide some sort of
"constructor" function that's defined in the same file in which the
class/struct is defined. This function will allocate memory for the
object using malloc()/new and return a pointer to it. Of course, since
memory allocated using malloc()/new has to be released using free()/
delete, you also have to provide a "destructor" function that does
this, and the user *always* has to call both the constructor function
and the destructor function *explicitly*, which is VERY cumbersome (as
opposed to C++ constructors/destructors, which are called
automatically at object creation/deletion, and which you don't always
need to provide unless you have to do some initialization/cleanup).

- Memory allocated with malloc()/new is allocated on the heap (as
opposed to variables that you simply declare locally, which are
allocated on the stack), and heap memory allocation is slower than
stack memory allocation (not that you have to worry about this
overhead except in really high-performance applications).

In short, you pay too high a price for using an object whose size
isn't known at compile time.

> 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++.

What limitations? The only limitations I see are the ones associated
with opaque types (what you mentioned above).