is python Object oriented??

[David Cournapeau]

On Tue, Feb 3, 2009 at 2:37 PM, Russ P. <Russ.Paielli 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.

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 ?

cheers,

David