is python Object oriented??
Russ.Paielli at gmail.com
Mon Feb 2 22:51:11 CET 2009
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
> 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
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.
If a "private" keyword (or equivalent) were available, then the change
would need to be made in only one location rather than at every
occurrence off the identifier. That is much less error prone. Sure,
you can argue (as I'm sure someone will) that the users of the library
should be more careful. Yes they should, but why not let the language
help with such low-level details. That's what high-level languages are
Several people have argued that an advantage of the leading-underscore
convention is that it tells you at every occurrence of the identifier
that it is private. Of course, the leading-underscore convention could
still be used even in combination with enforced access restriction.
But the larger point is this: that is like saying that global
parameters should be repeated as literal numbers at every occurrence
so the user can see the value instantly. Sure, that saves you the
trouble of looking up the value when you need to know it, but it also
requres that any change must be carefully made at every location. No
competent programmer would argue in favor of that.
More information about the Python-list