Steven Bethard wrote: > The complications with attribute hiding is one of main reasons I've > tried to minimize the number of methods associated with Bunch...
in order for bunches to be fully useful in general, open contexts, I think that number of methods should be exactly zero (at least without leading underscores). Otherwise, as soon as someone loads a config file into a bunch and they assign randomname_which_you'd_used, the whole thing breaks. I see two ways to implement additional (needed) functionality into bunches: 1. The class/staticmethod approach. This has clean syntax, though it may make inheritance issues tricky, I'm not too sure. 2. To break with pythonic convention a bit, and make the public API of Bunch consist of methods which all start with a leading _. You can even (via __setattr__ or metaclass tricks) block assignment to these, and state up front that Bunches are meant to hold public data only in attributes starting with a letter. I think that would be a reasonable compromise, allowing you to do: b = Bunch() b.update = 'yes' b._update(somedict) b.copy = 'no' c = b._copy() # BUT: c._update = 'no' ## an exception is raised etc. It's not very pretty, and it does break with pythonic convention. But a Bunch class which simultaneously provides certain non-trivial functionality (otherwise the usual 'class Bunch:pass' idiom would be enough), while allowing users to store arbitrarily named attributes in it, is inevitably going to need to play namespace tricks somewhere. FWIW, I personally could live with #2 as an acceptable compromise. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
