is python Object oriented??

[thmpsn.m.k at gmail.com]

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?

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

Sure, hey, let's do OOP in C, using structs, POD STRUCTS (!!!!), and
PLAIN FUNCTIONS (!!!!) !!!!

Heck, why do we even need OOP?? Long live procedural!!

We don't even need no stinkin programming languages, we could just
program using 1's and 0's!!!!!!!!!

What's with this luddite attitude, Python community?

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