Why does python not have a mechanism for data hiding?

Fuzzyman fuzzyman at gmail.com
Sun May 25 06:01:35 EDT 2008


On May 25, 2:28 am, "Terry Reedy" <tjre... at udel.edu> wrote:
> "Benjamin Kaplan" <benjamin.kap... at case.edu> wrote in message
>
> news:ec96e1390805241357i6e481e3enf12b4d213e887008 at mail.gmail.com...
> | On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <fuzzy... at gmail.com> wrote:
> || > For example, at Resolver Systems we expose the spreadsheet object
> | > model to our users. It hasa public, documented, API - plus a host of
> | > undocumented internally used methods.
> | >
> | > We would really *much* rather hide these, because anything our
> | > customers start using (whether documented or not) we will probably
> | > have to continue supporting and maintaining.
> | >
> | > The 'we told you not to use that' approach, when applied to paying
> | > customers doesn't really work... all they see is that you broke their
> | > spreadsheet code by changing your API.
>
> Python was not really written with 'difficult' customers in mind ;-)
>

True. It's extremely suited to what we do though.Minor difficulties
like this are vastly outweighed by advantages. The difficulties are
real though.

> One could largely hide private vars with a program that substituted random
> names for single _ names, and removed the doc strings for functions,
> classes, and methods with such names.
>


We need to *use* those names to display the spreadsheet once the
calculation has finished (and their code has run).

> Such a program could even put such names in a separate module imported as
> '_private_do_not_use_'.

Splitting more of the functionality out is probably part of the best
solution.

Michael Foord
http://www.ironpythoninaction.com/



More information about the Python-list mailing list