On May 24, 9:14 pm, Fuzzyman <[EMAIL PROTECTED]> wrote: > On May 24, 2:58 pm, Ben Finney <[EMAIL PROTECTED]> > wrote: > > > Sh4wn <[EMAIL PROTECTED]> writes: > > > first, python is one of my fav languages, and i'll definitely keep > > > developing with it. But, there's 1 one thing what I -really- miss: > > > data hiding. I know member vars are private when you prefix them with > > > 2 underscores, but I hate prefixing my vars, I'd rather add a keyword > > > before it. > > > From whom are you trying to hide your attributes? > > Actually, 'data hiding', although vastly overused by the static crowd > can be a reasonable thing to want. > > 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. > > You can make members truly private by proxying, but it is a bit > ungainly.
Then don't document it, or separate internal documentation (which is never to pass through the wall) and public documentation (which your users use). Nobody would (apart from your dev team and anyone told by your dev team, which means you may fire the person for "lack of discipline") know that there is such a thing and in consequence wouldn't use it. Don't tell your user not to use something, just don't tell them that it exists and they won't use it. -- http://mail.python.org/mailman/listinfo/python-list
