[goodoldneon]

We write wrappers for standard and third-party libraries that throw errors. For example, we have our own dump_json function that catches-and-returns errors thrown by json.dumps.

We didn't need many wrappers given the nature of our SDK, but some programs will need many wrappers and that could get unwieldy

[dmurray]

But people are going to import your SDK, so your customers will be stuck with a mix of thrown exceptions and errors-as-values in their code.

Based on your decision to write wrappers internally, presumably you'd argue that the sensible thing for them to do is to write wrappers either for your SDK or for every other library to get back to a consistent style and less mental overhead.

[goodoldneon]

Author here!

We don't return errors in our public methods so our SDK still feels Pythonic. We're debating whether to add `_safe` suffix methods that return errors to give people the option, but for now our library only throws errors to consumers.

You might ask "well what's the point if you still throw errors to consumers?" We feel that forcing our engineers to deal with errors where they can happen is worthwhile. Our team writes a lot of Go and we love how it forces you to think about every spot that can error, so we wanted the same experience in Python

[dmurray]

OK, in that case I think it's a very reasonable choice! Perhaps it's worth clarifying that in the article.

I might express a slight preference that your internal code is idiomatic if I'm going to be poking around in there at some point. But I wouldn't be bikeshedding about your C coding style if you'd provided a Python module written in C, so I don't feel I should have a strong opinion as a user here.