Aahz Maruch aahz at panix.com
Thu Aug 9 18:38:33 CEST 2001

In article <3B704ED1.EFA6AEA8 at demog.berkeley.edu>,
Lloyd Goldwasser  <goldwasser at demog.berkeley.edu> wrote:
>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?

Side note: the canonical way in Python of indicating "private" is to use
a single leading underscore.  Use name-mangling only when you must.
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Hugs and backrubs -- I break Rule 6                 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista   

"i-write-best-when-the-audience-is-me-ly y'rs  - tim"

More information about the Python-list mailing list