is python Object oriented??

[thmpsn.m.k at gmail.com]

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;

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