Python as an Object Oriented Programming Language

[Hrvoje Nezic]

> 3. Multiple inheritance.
>
> I have read this citation by Zack Urlocker "Multiple Inheritance is the
goto of
> the 90's" and various recommendation against it. On top of that, various
> languages forbid it by design, because it is a Bad Thing. Nevertheless, it
> doesn't seem so evil to me in Python, I also have seen a paper by Chuck
Esterbrook
> about Multiple Inheritance and mixins as a very useful technique. I think
the
> original quotation referred to C++ where multiple inheritance is such a
mess.
> OTOH, it doesn't seems very difficult or very dangerous in Python once you
> have understood the Method Resolution Order. Am I correct ? What are the
general
> guidelines of the Python community about multiple inheritance ?

As Mike Meyer said, the problem is not with multiple inheritance itself,
but by bad implementations in some languages. It can introduce conflicts,
and languages have to include mechanisms to resolve them. C++ doesn't have
such mechanisms, Python also. Eiffel contains such mechanisms (and it is
a very good language in many other respects). See www.eiffel.com .

Pure object oriented languages treat basic types like integers, floats,
booleans,
string, arrays etc. in the same way as other types. This is not an academic
question, but a very practical issue. For example, in some languages you
must write copy constructors or operator=, just to copy an object to
another one.
Imagine writing and maintaning such code for every class you write.
A pure object oriented language has methods like "clone" that
are defined at the top of object hyerarchy and work for every class, being
it integer, array, or any user's class. You get this functionality
automatically.

If you want to write serialization methods, again, in non-pure O-O langauges
you must treat basic types and other types differently, which means that
you'll
end up writing lots of unnecessary code.