is python Object oriented??

[Stephen Hansen]

>>
>> You, sir, should be programming in some language other than Python.
>
> Why?  - Python is object oriented, but I can write whole systems
> without defining a single class.
> By analogy, if data hiding is added to language, I could write a
> whole system without hiding a single item.
> Conversely, the lack of data hiding is perceived as a weakness,
> and IMO harms the advocacy of the language -

This is an alarming statement.

Advocacy should advocate the language-- it must not define the language.

If a fundamental principle of the language harms the advocacy of the
language: then the problem is not with the language but the advocacy.
If you are going to advocate a thing: advocate that thing. Don't try
to change that thing into what it is not so as to make your advocacy
the end-goal.

One of the reasons I love Python is because its practical first. It
begins with its license, which some people argue allows companies to
steal effort from its developers to use for their own purposes without
contributing back. The Python license is about empowering people to
accomplish things, to do things. It goes further. Guido and the core
developers ask real questions: would this add a burden to practical
use, or would it hinder another practical use?


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

Part of my lack of understanding might be because people couldn't read
my previous messages because my mail client's configuration
accidentally got fubar'd and I was sending HTML mail instead of plain
text. But my question remains: Why do you need forced encapsulation?

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.

If you are writing end-level code, you can achieve forced
encapsulation by simply not playing with anyones privates. If you are
in a corporate environment who has rules about accessing privates
written by another team for valid reasons, your policy to not do so
should be enough or your review process should pick it up. If you are
in an open source environment accepting patches from various people,
you should have a clear policy about the subject if you think breaking
encapsulation is never acceptable and refuse the patches. Those who
have commit access and violate encapsulation anyways against your
projects policy are problems that you clearly need to deal with. The
problem is not the language at that point, its the contributor.


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

If its your projet which someone else is using, and accessing your
internals that are clearly private and not documented: its not your
problem if they stab themselves in the foot. On the contrary, why in
the name of all that is holy, do you care if they manipulate your
internals at their own risk, at their own cost, and achieve something
positive for them? How in any way does this hurt you?


>  that an underscore convention is
> "just as good", (It isn't),

Why isn't it?

> that you could crack it if you really
> tried, (so what?),

Exactly.. so what? WHY is the convention not enough? What REAL
situation is there that the lack of *forced* encapsulation but policy
based encapsulation not enough?

> Surely if "we are all adults here" we have to accept that the
> other man has as much right to get what he wants, as
> anybody else, and that his reasons are as valid as those of
> anybody else.

Yes., We're all consenting adults.

But if one adult decides to make rules that the other doesn't agree
to, is that consenting adults, or is that rape? I apologize for the
use of the term, but "consenting adults" has particular connotations
that seem to apply very well here, in the context of that expression.

Forced encapsulation allows one party to make absolute rules and hold
absolute authority over another party.

If you believe that encapsulation should never be broken: do not break it.

If your organization, corporation or project believes that
encapsulation should never be broken: specify that it must not be
done. Your review process (you do have one, right?) will pick it up
and you can very quickly deal with the situation.

Encapsulation is a very, very good thing in general: but it is a
question of *design* and not *implementation*.  Python allows EVERYONE
who wants encapsulation to HAVE it. Not forced encapsulation, but
encapsulation. If you're producing a product in Python on your own
simple policy and trivial review (even -automated- review; it is NOT
hard to tell that "other._private" is not "self._private") provides
encapsulation.  If you're making a library for others to use, there is
no valid reason for you to care if they screw with your internals.

Really. I just don't get the problem. It seems to me that people who
want this in Python will never be happy *in* Python. Its a very deep
fundamental feature that Python exposes everything it can, even things
that are potentially dangerous like sys._getframe. Recently on
Python-dev(note: I only lurk) someone was working on a debugger and
they were told in that situation it was OK to access a private member
of sys to achieve an end: exposing that internal to general use just
had no value. That's the Python Way. People can dig into things,
classes, functions, and screw around in wild ways if they want to.
That *is* what Python is. 95% of code by 95% of people won't ever go
there, but its there. To remove it means its *not* Python.

--S