@Caleth I've never seen that definition of "magical". Maybe there's a better term, such as "not part of function signature". The "errno" pattern allows the OP to chain operations and be able to get diagnostic info, which he apparently wants to do. So it's a tradeoff between convenience in programming and clarity of interface. OP doesn't say how broad consumers of APIs are - my guess is small # of consumers. In which case the errno pattern's benefit probably outweigh disadvantages. Of course you could combine chaining with error info, by accepting your struct as inputs, but that's overkill IMO

I was going to suggest essentially this - see what types of configuration files Python libs support and pick one of those. Also, Powershell has the notion of data sections - which allow limited Powershell language constructs - protecting against malicious code. If Python has a lib that supports a limited subset of Python for configuration, that at least mitigates one of the cons against the idea in the OP.

I disagree on some points. errno doesn't have to be a static location, it can be macro that evaluates to any number of things, including a thread local variable. I don't consider it magical, because all the C libraries I've seen that use it, document it's use. When a function returns a value, you can't unambiguously tell from prototype that it can signify an error. You must look at documentation. There is a great body of evidence that suggests success with its use. Also, it's a common pattern in hardware architecture: Machine Check Architecture for x64, AER for PCIe, APEI for ACPI, etc

@user1118321 I'm aware of difficulties with errno in a multithreaded environment, and with ambiguities WRT when errno changes, but are you referring to other "brokenness"?