is python Object oriented??

[Bruno Desthuilliers]

thmpsn.m.k at gmail.com a écrit :
> 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. 

Not exactly the same purpose, indeed, but there's still something close: 
mark the names as "special".

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

And here again : "would break", "shouldn't", "supposed". Convention over 
enforcement.

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

So what ?

> CHAOS MAY ENSUE!!

C is not really a new technology, and has been the basis for most 
systems for years and years. Looks like nothing that bad as "CHAOS" 
really happened so far...