Re: is python Object oriented??

"Stephen Hansen" <apt.shansen@xxxxxxxxx> 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


.

Relevant Pages

  • Re: Replacing new?
    ... But encapsulation itself is not related to private and protected: ... The reason is - user needs it. ... errors after that - responsible for that is fully programmer, ...
    (comp.lang.javascript)
  • Re: Replacing new?
    ... The reason is - user needs it. ... Here's a good example how encapsulation is made in Python: ... and I agree that concealing one's private parts ... // reduce sandwich size ...
    (comp.lang.javascript)
  • Re: is python Object oriented??
    ... You, sir, should be programming in some language other than Python. ... Advocacy should advocate the language-- it must not define the language. ... Why do you need forced encapsulation? ...
    (comp.lang.python)
  • Re: Why does python not have a mechanism for data hiding?
    ... Now Python has both. ... the attribute with a single leading underscore. ... Nearly every introduction to OOP? ... support for encapsulation then it does not have encapsulation. ...
    (comp.lang.python)
  • Re: Need help with Python scoping rules
    ... Python does not fully support class-level encapsulation. ... be in scope at runtime. ... the problem has nothing to do with recursion: ...
    (comp.lang.python)