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