is python Object oriented??

thmpsn.m.k at gmail.com thmpsn.m.k at gmail.com
Wed Feb 4 14:49:32 EST 2009


On Feb 4, 3:11 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> thmpsn.... at gmail.com a écrit :
>
>
>
> > On Feb 3, 1:14 am, David Cournapeau <courn... at gmail.com> wrote:
> (snip)
> >> 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;
> >         };
>
> Didn't you notice kind of a pattern here ?

You mean the leading underscores? I don't think they're used for the
same purpose as in Python. In C/C++, identifiers that begin with an
underscore are reserved (at least at the outer level). Thus, if the
member '_ptr' would instead be named 'ptr', something like this would
break things:

#define ptr // OOPS!!
#include <stdio.h>

That shouldn't happen with '_ptr', since programs are not supposed to
define those kinds of names (yeah, right).

> > 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!!
>
> Indeed - and that's exactly the point : nothing prevents you from
> accessing the implementation, *and yet, you don't*

I sure don't, but I still *can*.

CHAOS MAY ENSUE!!




More information about the Python-list mailing list