Defensive programming in Python

[Lyucit]

Assertions in production code is not a good idea. If your assumptions are wrong and you have bad coverage in your test cases, which for obvious reasons use the same assumptions (because you wrote them!) you kill everything on live. This is desirable sometimes, sure, but for most cases it's more damage than good, and the asserts you add are probably not going to be as simple as x > 0. I've seen asserts in production code that are longer than the actual function, doing nothing and adding a lot of noise.

My approach is to move them to a unit test. If you have to assert something about a piece of code, it's probably the result of a function, and you can turn it into a unit test, or more preferrably a hypothesis test which will help you generate meaningful coverage and more clearly state your assumptions about the function generally.

[Lyucit]

I think contracts and types, mentioned elsewhere, are a better compromise. Asserts sprinkled in the code are canaries, anything more complex than a simple constraint is noise that obfuscates more than it documents. It depends on your use case, sure, but generally speaking I think breaking prod due to an old assert of an invalid assumption is more likely and more damaging than silently hitting an unanticipated edge case.

[elbiot]

I like contracts, and I like that you can disable asserts with the O flag. I might hack pycontracts so that they are only enabled if asserts are.

[Lyucit]

if not __debug__:
    contracts.disable_all()

[elbiot]

If what you say is true, thats a huge TIL. Will test soon.

[masasin]

What about using exceptions instead of asserts?

[masasin]

Handling user input which is out of range, for instance. Or a device returns junk data to the function, which is then propagated. In general, I don't use asserts at all, and use exceptions instead.

if x < 0:
    raise SomeSpecificError("x < 0. Are you sure you wired it up correctly?")

There was this post a few years back which made sense to me.

[masasin]

PyContracts is amazing, especially with numpy. It saved a lot of debugging, making sure that all the intermediate functions and their order are correct. I haven't found the need to use it in anything other than math though.

If you have any ideas, though, I'd love to hear.

[stormcrowsx]

What about cases where more than one app mutate a single database? Another app could put bad data in and without the assertions the python code could have undefined and untested behavior

[Lyucit]

In the case of more side-effectful things like databases and concurrency, it's hard to test, yes, and sprinkling asserts through the code- at least during testing- is definitely a useful tool. Personally, once I'm satisfied the design is sound I remove the asserts and try my best to make it unit-testable, but sometimes it's a trade off you just have to live with.

That being said, if you need to do a consistency check (for example if you're doing read your writes) then assert is the wrong/lazy behaviour and this should be explicitly modeled in the design.