is python Object oriented??

[Benjamin Kaplan]

On Mon, Feb 2, 2009 at 4:51 PM, Russ P. <Russ.Paielli at gmail.com> wrote:

> On Feb 2, 9:02 am, thmpsn.... at gmail.com wrote:
> > 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.
>
> I couldn't agree more.
>
> As I said before, as an aeronautical engineer I don't know if enforced
> access restriction can be added to Python without compromising or
> unduly complicating the language. Maybe it can't. If that's the case,
> then people should make that argument. But just saying that enforced
> access restriction is useless in general is nonsense. Are we supposed
> to believe that the designers of C++, Java, Ada, and Scala are all
> idiots?
>
> Several participants here keep repeating that the leading-underscore
> convention is perfectly adequate. Aside from the aesthetic problem of
> littering code with leading underscores, let me try to explain the
> problem with leading underscores.
>
> Suppose a library developer (or a module developer on a large team)
> uses leading underscores. Now suppose that, for whatever reason
> (pressure from the users, perhaps), the library developer decides to
> change a "private" attribute to public. Now all occurrences of the
> identifier need to be changed. If an assignment to the previously
> "private" attribute is missed, no warning will be issued (because
> Python allows new attributes to be added anywhere, even completely
> outside the class definition itself). And if the library is widely
> used, the probability of such bugs occurring is very high.


1. This would be a great spot to use a property. Problem solved.
2. Unit tests. Lots of unit tests.
3. Pylint will check for uninitialized fields. It won't stop you from
running the code obviously, but it will notify you if you forgot to change
something.
4. Find/Replace. Takes the effort out of looking for the places to change
the name.


[long argument for private keyword]

> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090202/30f0c9ae/attachment-0001.html>