encapsulation?

[Steve Holden]

"Lloyd Goldwasser" <goldwasser at demog.berkeley.edu> wrote in message
news:3B704ED1.EFA6AEA8 at demog.berkeley.edu...
> 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
> 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
> 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?
>
This is known in Python as "programmer discipline". If you want all object
access to be through defined interfaces, then simply don't use direct
attribute access! Unfortunately this does mean that unknown clients of your
code can abuse your namespace without your knowing, so I suppose Python
might not suit all project environments. Pythonistas are pragmatists, by and
large.

regards
 Steve
--
http://www.holdenweb.com/