On May 25, 2:28 am, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Benjamin Kaplan" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > | On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <[EMAIL PROTECTED]> 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/ -- http://mail.python.org/mailman/listinfo/python-list
