is Python fully object oriented ?

[Jan Dries]

Ben Hutchison wrote:
> 
> Crutoy wrote:
> 
> > Hi , i haven't used Python but i do have experience in other languages vb ,
> > java , c++ . Is Python a fully object oriented ? Thanks
> 
> I have just been considering the same questions myself. I do have a few
> concerns with Pythons OO credentials, relative to Java/C++.
> 
> 1. Most significantly, Python requires the "self" or "this" reference to be
> explicitly declared. This seems like a bit of a hassle if you do pure OO
> development with python; lots of typing! 

This is a design choice (the "explicit is better than implicit", one of
Python's favourite design choices), and as any design choice, a
compromise. It makes things more explicit. Whether you consider that to
be an advantage or a disadvantage depends on your point of view. Yes, it
requires more typing, but it also protects you from the complexity of
the many sometimes subtle disambiguation rules that C++ has to correctly
deal with the implicit use of "self" or "this". 

In either way, it has nothing whatsoever to do with the concept of OO.
It's a language implementation design choice, that, as it happens, makes
both using and implementing Python more straightforeward.

And FWIW, I have been a core C++ afficionado for more than 10 years, and
I liked it so much for it's impliciteness and conciseness. About a year
ago, I discovered Python and have since then written thousands of lines
of Python code, yet have not once experienced the typing of "self." to
be overhead, and further, although it's less important for myself as a
programmer, I find that some of my not so experienced team members have
much less trouble getting up to speed with the explicit Python approach
than with the more implicit C++ approach. 
Besides, when it comes to typing, even with the explicit "self.", Python
is still far less verbose than Java.

> Suggests perhaps that OO features were
> built onto initially procedural language.
> eg: Python
>     class MyClass:
>         def __init__(self, name):
>         def doIt(self):
> Python with implict self (as in C++, Java)
>     class MyClass:
>         def __init__(name):
>         def doIt():
> 
> 2. Access control is more informal in Python than C++/Java. I know in the case
> of Java at least that security provisions depend in part on access control
> being strictly enforced, and additonally there are a number of design
> principles that assume 3 tiered (public, protected, private) access levels.
> * Is Pythons leading underscore mechanism more of a convention?

The underscore approach is more than a convention:
Names prefixed with a single underscore are not imported by the "from
module import *" statement, and hence must be explicitely imported.
Names prefixed with double underscore are explicitely mangled so they
can't be mistakenly accessed from outside their class for instance.

> * It is strong enough to build security mechanisms on?

Even the C++ support for public/protected/private access is not strong
enough to enforce security. Quoting Stroustrup (in "The C++ Programming
Language", 3rd ed. p. 226): "The protection of private data relies on
restriction of the use of the class member names. It can therefore be
circumvented by addressing manipulation and explicit type conversion.
But this, of course, is cheating. C++ protects against accident rather
than deliberate circumvention (fraud)."
In that light the Python underscore approach does not differ from C++.
You can circumvent it, but you must explicitely do so. Although in
Python it is arguably easier to do so than in C++.

> * Can a class declare a priviledged API availalbe only to subclasses?

Here you refer to the notion of protected members. There is concensus in
some circles that protected was a bad idea in the first place. Protected
was invented for C++, and Java copied it. But Bjarne Stroustrup,
inventor of C++, now says it was a mistake introducing protected,
because it is a source of bugs and seriously complicates maintenance.
Quoting him again (in "The design and evolution of C++", p.302):
"Barbara Liskov's OOPSLA keynote [Liskov,1987] gives a detailed
explanation of the theoretical and practical problems with access
control based on the protected notion. [...] In fact, one of my concerns
about protected is exactly that it makes it too easy to use a common
base the way one might sloppily have used global data. [...] In
retrospect, I think that protected is a case where 'good arguments' and
fashion overcame my better judgement and my rules of thumb for accepting
new features."


The bottom line, IMO, is that Python has managed here (as with so many
other aspects of the language) to provide a very simple approach that at
least in practice is just as effective as the equivalent C++ or Java
feature, but at a fraction of the overhead and complexity. It is, for
example, extremely challenging to even try to understand all the
subtleties of acces control or multiple inheritance for that matter in
C++. In Python, all of this is simple to explain, just a handful of
simple rules, and simple to use, but as features in practice just as
effective as in C++.

Regards,
Jan