> On 13 Jan 2017, at 13:09, Nathaniel Smith <n...@pobox.com> wrote: > > I guess another possible point in the design space would be to split the > difference: instead of an abstract context class or a dict, define a concrete > context class that acts as a simple transparent container for these settings, > effectively layering the type safety etc over its __dict__.
I think I’d want to do it this way if we were going to do it all: I’m extremely reluctant to use dicts and strings for this if we can possibly avoid it. In fact, you’ll note that the API goes to substantial lengths to avoid passing strings around in almost all cases, except where such a use is required essentially by convention (e.g. paths). While we’re here, I should point out that this does not replace the abstract contexts entirely, because we still need the wrap_* methods. These would now just be fed a Configuration object (I’m more comfortable with the name Configuration than Policy for this usage) in their constructor, and then could use the wrap_* methods as needed. How does that idea sound to the rest of the list? Cory
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
