is python Object oriented??

[Thorsten Kampe]

* thmpsn.m.k at gmail.com (Mon, 2 Feb 2009 09:02:13 -0800 (PST))
> On Feb 2, 2:55 am, Stephen Hansen <apt.shan... at gmail.com> wrote:
> > > This is proven
> > > by your statement above, whereby you are driving a user away,
> > > simply because the language, in one small aspect, does not
> > > give him what he wants, and the tenor of this thread has been
> > > very much: "That's how it is - like it or lump it", and no amount
> > > of careful explanation of why people want the feature has cut
> > > any ice -
> >
> > I'm missing the careful explanation. What I've heard is that the lack
> > of enforced encapsulation is "a danger". What I've heard is that
> > people want it because they've been told they should want it and
> > believe that. Why?
> 
> Who has said the latter? Are you just trying to spread FUD?

No, he's not. He's giving his and other people's impression of the pro-
private group's arguments. They construct cases that do not exist in 
reality or can more-than-easily be avoided.
 
> > There have been no "careful explanations" to answer that, in my mind.
> > And thus my response is: the practical possibility of needing access
> > vastly outweights the theoretical situation that might go bad if
> > encapsulation wasn't there. Why? Because in any real situation, IMHO,
> > *forced* encapsulation is pointless.
> 
> I think you've gotten too subjective on this matter. You might as well
> say that we don't need no stinkin' OOP, we could all just be
> programming with goto's.

It's even simpler: "don't use other people's underscores". It couldn't 
get more simple than that. 

> > > It has all the time been countered with statements
> > > about how the proponents of private attributes "don't need it",
> > > (as if they are plain dumb),
> >
> > They don't need it. No one has shown a *real* reason why. The only
> > reasons provided are "its a DANGER" that someone "MIGHT DO BAD".
> > That's not a real reason. If its your project that someone is doing
> > bad in, this is a situation which can be *clearly* specified in a
> > projects policy and coding standards and can be *trivially* tested for
> > with simple static analysis in nearly all cases. The problem is the
> > person and not the code then. There's *countless* other ways that
> > person can do bad if you're allowing them to commit blindly anything
> > into your project.
> 
> Aha! I see this attitude quite often among C/C++ people, regarding
> buffer overflows and uninitialized pointer dereferences: someone will
> say "C and C++ are unsafe languages because they allow you to overrun
> buffers", then a C/C++ zealot will respond "Hire some good
> programmers".
> 
> SAME ATTITUDE.

Not at all. Buffer overflows cannot be easily avoided in C/C++ like 
languages. On the contrary you can easily avoid other people's privates 
by simply not using their underscores. It's really that simple. Even I 
got that - and I'm a really simple guy.

Thorsten