…ing a common interface between a simple decentant of object and a more useful custom class (simple bunch vs. PysonBunch). Abandoning this effort for now, until a situation arises where it is actually definitley useful to have a "SimpleBunch".

Just inherit from dict.
Advantage: No object breakage due to name collisions, when storing in the dict.
Disadvantage: Dict introduces new name pollution with names which you may well want to use in PySON, such as the name "update".
(not a polished solution, just for history)

Keeping this in a commit, but planning to move on to Option 3: Inherit from dict, but rename the members via a metaclass, adding a configurable prefix, so that collisions can be easily avoided per application.

…mentation of bunches is that you can support an *approximate* dict interface and (the following part is not yet implemented) redirect user values to a separate dict, which should allow preventing any ill side-effects which might arise from name collisions between PySON names and python dict/object names.

This whole thing does not appear to be necessary on cpython, however, since the python interpreter does not seem to get upset by those name collisions (it looks up special properties on the class, rather than the instance) and user code still receives whatever value may have overriden a built-in name. Thus this branch will be left to collect dust, at least for now.