On Oct 22, 8:48 am, Robert Kern <robert.k...@gmail.com> wrote: > On 10/21/10 6:19 PM, Raymond Hettinger wrote: > > > I would appreciate any feedback on the API and on how well it fits > > with various use cases that you've found in the wild. > > We've done something similar in the past: > > https://svn.enthought.com/svn/enthought/CodeTools/trunk/enthought/con...
Right. This looks substantially similar. The shortened url is: http://tinyurl.com/3xh377k > I'm not sure we'd have much use for a batteries-included collections.Context, > per se, since we needed the other features of our Context implementation like > notification and restriction. In particular, we were using our MultiContext > with > subcontext mapping objects that could restrict the types of values that were > contained in them. We wanted to execute code in a MultiContext and be able to > separate functions and classes that were defined or imported from other > variables for display. That's an interesting additional layer of sophistication. One part that make be applicable to the current recipe is individual marking individual context as "allow" to enable __setitem__ for that level. My approach was to mark the child context as being able to mutate any of its parents. > As for the API, I would probably want to be able to create a Context simply > given a list of existing maps rather than needing to build a chain of them > using > .new_child(). Most of the use cases I can imagine are ones where I already > have > populated dictionaries, and I just want to slap this behavior on top of them. That makes sense. I should modify the constructor to allow a succession of existing dicts. > Other than that, it looks good. Thanks for reviewing the recipe. Raymond -- http://mail.python.org/mailman/listinfo/python-list
