is python Object oriented??

[Hendrik van Rooyen]

"Stephen Hansen" <apt.shansen at gmail.com> wrote:



8<----------- arguments for the status quo ------
> 
> 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

Repeating it, (despite my assertion lately in another thread) does not 
make it true - what follows is simply an opinion on how to solve
the problem "by management", instead of providing a different tool.

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

Because it needs human intervention.

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

See human intervention above - and as for 
"real, forced data hiding" - have you ever
coded anything that produced a segmentation fault?

I wonder why the designers of processors do such silly things as having
user and supervisor modes in the hardware - according to your
arguments a code review would solve the problem, and then they
could use the silicon saved to do other usefull stuff. - then any process
could use any instruction, and it would be all right. - easy to manage
out of the project - you just have to scan the object code for op codes
that you have decided are dangerous (for whatever stupid reason). 

Another example out of the processor world is the fact that some
modern processors actually force a process to keep in its own 
memory.  What temerity! Who do these idiots think they are
to try to keep "me" from accessing "your" memory - after all, 
I have a good reason - (I'm inquisitive)

This is of course rather more difficult to pick up in a code review,
as I could easily calculate the address, which makes it not
immediately apparent that I will access something not belonging 
to me.  And seeing that Python is not dynamic at all, there is
no analogy here...

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

I do not agree with this. If _I_ write a module, and _I_ use forced 
encapsulation for _my_  purposes ( however misguided you might 
think I am) then how does that affect _you_?

Even if I release the thing into the wild - you do not have to use it
if you feel you really *must* muck around with the equivalent
of Steve D'A's example of the length of a builtin - you could write 
your own, or fork what I have done. - It seems that by denying me
the use of such a feature, you are the one trying to make absolute
rules, for *your* benefit - *you* want to use *my* stuff, on *your* 
terms, without having to bother to put any effort into it.

8<----- repeat of "code review cures all" argument ------

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

Now there are a LOT of dicey statements in the above passionate 
plea - python is a language, and not a philosophy, but I won't go 
into that, as that would lead off onto a tangent, of which there have
been a surfeit in this thread.

But this needs addressing:

Nobody is saying that "Python" should change the way "Python" 
exposes stuff - All that is being requested that *I* should be 
allowed to use python to expose as much of *my* class as *I* 
deem fit, for *my* purposes.

And some form of "private" keyword would do that nicely, 
thank you, and keep the current "public" default unchanged.

Now this is from a user perspective - It may prove to be
difficult, if not impossible, to implement in CPython.  I just
don't know enough details of the implementation to be able 
to tell.

Maybe what is needed is some form of *Interpreter* vs. 
*User* state, analogous to what is done in the hardware,
with defined, "code reviewable, testable for",  procedures 
for switching between one and the other.

- Hendrik