On 13 January 2017 at 19:33, Nathaniel Smith <n...@pobox.com> wrote: > On Fri, Jan 13, 2017 at 1:09 AM, Cory Benfield <c...@lukasa.co.uk> wrote: > I get what you're saying about a typed API -- basically in the current > setup, the way _BaseContext is written as a bunch of Python methods > means that the interpreter will automatically catch if someone tries > to call set_cihpers, whereas in the dict version each implementation > would have to catch this itself. But in practice this difference seems > really minimal to me -- either way it's a runtime check
The difference isn't minimal at all from the perspective of: - static type analysis - runtime introspection - IDEs (which use a mixture of both) - documentation Config dictionary based APIs have *major* problems in all those respects, as they're ultimately just a bunch of opaque-to-the-compiler keys and values. Network security is a sufficiently hard problem that we want to make it as easy as possible for developers to bring additional tools for ensuring code correctness to bear :) > and it's > really difficult to write a loop like > > for key, value in config.items(): > do_some_quirky_cffi_thing_based_on_key() > > that doesn't implicitly validate the keys anyway. There's also the > option of using e.g. JSON-Schema to write down a formal description of > what goes in the dict -- this could actually be substantially stricter > than what Python gets you, because you can actually statically enforce > that validate_certificates is a bool. For whatever that's worth -- > probably not much. I've generally found that it's easier to build a declarative API atop a programmatic API than it is to tackle a problem the other way around: 1. Even if the only public API is declarative, there's going to be a programmatic API that implements the actual processing of the declarative requests 2. Working with the programmatic API provides insight into which features the declarative API should cover, and which it can skip 3. Programmatic APIs are often easier to test, since you can more readily isolate the effects of the individual operations 4. A public programmatic API serves as a natural constraint and test case for any subsequent declarative API Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
