is python Object oriented??

[Hendrik van Rooyen]

Hendrik:
> > I wonder why the designers of processors do such silly things as having
> > user and supervisor modes in the hardware - according to your
> > arguments a code review would solve the problem, and then they
> > could use the silicon saved to do other usefull stuff. - then any process
> > could use any instruction, and it would be all right. - easy to manage
> > out of the project - you just have to scan the object code for op codes
> > that you have decided are dangerous (for whatever stupid reason).
> 
Diez:
> This is comparing apples to oranges. Forced data encapsulation or not take
> place *inside one process*. So this whole argument is a straw-man.

I do not agree with this, but then I won't will I? 

The reason is that I see a level of abstraction that makes it kind of
irrelevant whether something is run as a process, a thread, a time
multiplexed mainloop, on one or more processors, wherever or 
whatever - almost like a fractal structure spread across the total 
addressable space - and I would like to use the same rules 
everywhere.  And if there are reasons for forced encapsulation
*somewhere*, then it is more elegant (to my taste) to allow it 
*everywhere*.  - and conversely, of course.  Hence the rather 
*an der Haare herbeigezogen* (see ** below) argument 
based on the forced restrictions in processors.

I see almost any piece of code that "does something" as a black
box that has inputs and outputs - and I like to string them together
in a style that resembles a systolic array - closer to unix piping ,
based on true queueing and message passing, where it becomes 
at all practical.

Given this approach, there is no reason whatever for anything
to mess with any other thing's innards - in fact the less you know 
about it, the more robust and predictable the system becomes.

And in embedded processes, there exist things that are time
critical, that are designed to be used in one way, and no other,
and that can have serious consequences if messed with- when
I have started moving the 100 tonne mass, then I *cannot* tolerate
other code changing my timeouts or speeds or feeds in an arbitrary
fashion - EXPENSIVE noises will result.

> I've seen a lot of programs segfault that are written in C++ with data
> encapsulation. And also a lot of them that overcame the restrictions the
> compiler or even runtime in java imposed on them, either by pointer-magic,
> or through some available backdoors that have been put in place for good
> reasons.

I think that segfaulting is basically caused by programming error - 
By the inability of the programmer actually to understand the 
limitations of the compiler to "do what I mean".

Encapsulation or data hiding will never "cure" that, because
at best it could move some of the errors from runtime to 
compile time.

I doubt the "good reasons for backdoors" part - I think that comes 
from a design that has either not been done, or used, at the correct 
level of granularity.

> So far I haven't seen any argument for forced data encapsulation that went
> beyond a matter of personal taste. That's fine, but also just that.

This could be true, and if it is, we are just beating our heads one against
the other, trying to win non existent prizes for pig-headedness.

I could also turn that argument around, as well as stating it stronger:

So far I have not seen any argument in favour of free access to
the internals of another piece of code that is based on ANY necessity,
(beside a handwaving "good reasons" ) or that goes beyond a matter
of personal taste based on a hacker's glee in meddling in somebody
else's code.

:-)

- Hendrik

** -*an der Haare herbeigezogen* German, literally "drawn closer by the hair"
expression denoting either a specious argument or a forced analogy.  Sorry,
but I could think of no English equivalent.