is python Object oriented??

[Diez B. Roggisch]

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

Your argument would be valid if *any* of the *languages* implementing
encapsulation would offer that real isolation. None does. So where from
comes the feeling that this must be something a *language* should offer?

Sure one could envision a system where each object is running in it's
micro-process. So far, this hasn't been implemented (to the best of my
knowledge) - so making assertions about the feasibility & robustness for
running as well as for developing are somewhat "airy", don't you think?

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

For a certain, very limited definition of robustness & predictability. 

As much as I like my OS not to go down, it's nothing that helps me to
accomplish my actual goal using it if the software running on top of it
crashes. From this POV, a chain is always only as strong as it's weakest
member. And that might well be one of your encapsulated components. 


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

Embedded programming most often even offers the memory protection one needs
to make the "real" encapsulation, due to hardware restrictions.

And even if it did,  it won't help you with memory corruption that occurs in
process. Which is of course a re-iteration of my argument.

Again: the expensive noises haven't been avoided because of encapsulation.
They might be the product of expensive testruns, either by trial-and-error,
or by review. Not by encapsulation.

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

The argument as apparent in Python: ducktyping is used everyday, to all our
benefit. And every piece of code that only works precisely because it was
possible to access the innards of some other piece of code is an example
and a reason to allow it.

You might say that these things are showing a lack of proper design - but
the point is that design is a question of perspective, and a otherwise
useful piece of code is rendered useless because of encapsulation if that
prevents the usage from a new perspective the original author didn't think
of.

That's my stance on this, and as a coder, I want to (re)use code, not work
around it.

Diez