is python Object oriented??

[Hendrik van Rooyen]

"Diez B. Roggisch" <deets at nospam.web.de>

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

No.  Not airy.  Hairy, yes.

I suppose the language is a kind of wish list on my part - 
I have spent the last twenty years or so writing stuff like this 
on small processors, in assembler, and I would have loved a 
language that supported it, as well as an operating system 
(and I do not mean stuff like tiny os and others of that ilk), 
but one that really supported fast task switching to make 
the micro tasks less expensive on cheap little processors 
with scarce resources. (8031) I have written various flavours
of my own, (pre emptive, round robin, cooperative) and they 
all suffer from the speed troubles associated with task 
switching on that architecture, but in all cases the performance
was good enough to get the job done.

Most of the stuff really did follow a dataflow model
as I have described, but its all so inextricably intertwined
with the hardware and the requirements of the different 
jobs that it feels kind of hopeless to try to extract general
principles from it, except for obvious stuff like that it works
better if your queues are formal and robust, and that the
messages must contain everything that is required to get
the job done.  If you do this, then there is really no reason
to worry about how some other thing is doing it's job.
In fact if you find yourself peeking at the other task's 
innards, then it means you have to rethink the dataflow,
because you are on the wrong track - that is what I meant
when I talk of "granularity"

I have find that code re use, between different projects,
has in my case been limited to some parts of:

- Task switching code
- The ticker structure to interface to hardware
- Queues, buffers and memory management.
- Utility functions like some simple math and string handling.

Anyway this is getting a bit far away from the python
way, which does not strictly enforce the 'Pure Path' (Tm)
of:

- have loose objects as threads/processes
- send messages between them using clever queueing

So we are extremely unlikely to agree on the importance
of enforced data hiding.

:-)

- Hendrik