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.
The problem is you're not hard enough, you let yourself to be enslaved by your customer. If they have a problem because they used a private interface, that's their problem, they have to fix it at their side or go away and use a competing product[1]. Even if they're paying customers they're not your master or your God, even if they're a larger company than yours. Python has an extremely good design because the BDFL doesn't just listen to everyone and create a product that tries to please everybody, no, he listens to those that have good ideas and tells the stupid ideas to go away and he applies a subjective decision which more often than not leads to a better python. [1] In most cases, they would become silent at this point and fix their code, because they know there is nothing they can do to change your decision. It's often more expensive to move to competing products so they'd either use old versions or fix those places where they've used private interface, and avoid using private interface in the future. > You can make members truly private by proxying, but it is a bit > ungainly. > > Michael Foordhttp://www.ironpythoninaction.com/ > > (snip) -- http://mail.python.org/mailman/listinfo/python-list
