encapsulation?

[gzeljko]

From: Lloyd Goldwasser <goldwasser at demog.berkeley.edu>
Subject: encapsulation?
> As a recent convert to Python (I have C, Objective-C, and Scheme, among
> others, in my past), I'm curious about its lack of encapsulation.  'Way
> back when I was using Objective-C -- and many other OO languages seem to
> have a similar perspective -- there was a lot of emphasis on the ability
> to keep the contents of objects independent of outside influence except
> via well-delineated mechanisms.  Security and reliability were cited as

Python has 'well-delineated mechanism', as you stated below,
name-mangling for private variables.

> major benefits of this approach: every object knew exactly what the
> outside world was going to see and exactly how the outside world might
> act to change its state.  Python provides only the private variable
> name-mangling mechanism for "encapsulating" the contents of objects, and
> it's weak enough that dir(ClassName) announces all of those "hidden"
> contents to the world, at which point they can be altered at will.  I

In C++ include files also 'announces all of those "hidden" contents to the
world'.
Private variables also 'can be altered at will' (tweaked via pointers).

Encapsulation is concept witch has nothing to do with difficulty to be
tweaked _intentionaly_. (IMHO)

encapsulation-is-not-abouth-security-ly-your's gzeljko

> wonder whether this approach, making encapsulation a matter of
> convention rather than something that's provided by the language, is a
> liability.  It would seem to make Python ineligible for use in projects
> that need a more reliable separation between objects and outside
> access.  How hard (or desirable) would it be to provide a stronger kind
> of encapsulation in Python?
>
> Lloyd
>