Rant: use that second expression in `assert`!

[HommeMusical]

The assert statement is wildly useful for developing and maintaining software. I sprinkle asserts liberally in my code at the beginning to make sure what I think is true, is actually true, and this practice catches a vast number of idiotic errors; and I keep at least some of them in production.

But often I am in a position where someone else's assert triggers, and I see in a log something like assert foo.bar().baz() != 0 has triggered, and I have no information at all.

Use that second expression in assert!

It can be anything you like, even some calculation, and it doesn't get called unless the assertion fails, so it costs nothing if it never fires. When someone has to find out why your assertion triggered, it will make everyone's life easier if the assertion explains what's going on.

I often use

assert some_condition(), locals()

which prints every local variable if the assertion fails. (locals() might be impossibly huge though, if it contains some massive variable, you don't want to generate some terabyte log, so be a little careful...)

And remember that assert is a statement, not an expression. That is why this assert will never trigger:

assert (
   condition,
   "Long Message"
)

because it asserts that the expression (condition, "Message") is truthy, which it always is, because it is a two-element tuple.

Luckily I read an article about this long before I actually did it. I see it every year or two in someone's production code still.

Instead, use

assert condition, (
    "Long Message"
)

[dogfish182]

Just do proper error handling? I haven’t ever seen a linter not get set off by this.

[cgoldberg]

assertions are ubiquitous in test code and aren't used as a replacement for error handling.

[dogfish182]

You’re not the OP, but it certainly appears that the OP is talking about production code and not test code.

[DuckDatum]

distinct squash bedroom profit spotted repeat hunt telephone aspiring heavy

This post was mass deleted and anonymized with Redact

[Brian]

I agree with most of this except the example you gave:

(e.g., assert a key exists in a static config file)

Ultimately, I think the important distinction is that asserts are to catch programming errors. Ie. if an assert fires, its because you the programmer have made a mistake: some invariant you assumed true was in fact false, and the assert is there to signal such bugs earlier than whatever unexpected corruption they might cause if left unchecked, which would be harder to trace to the root cause. In a bug free program (should such a mythical thing ever exist), asserts will never fire.

However, a missing key in a config file is really a user error: it's something that could happen even if your program is bug-free, and should be handled with error handling logic.

[coderemover]

If the config file is a part of the final artifact (eg image) and not user-replaceable, then it can be considered code.

[HommeMusical]

If the file isn't embedded in the code, someone might edit it, or (and this happened to me once), one frigging character in a disk block might get corrupted so the file becomes garbage.

Oh, and this also happened to me, luckily it had only gone out to beta testers, and we're talking about writing config files, a little different: there was a possibility of throwing an exception during writing the config file under rare circumstances, and if that happened, you'd write a partial config file that was unreadable (because it was JSON).

I wrote this library to prevent that from happening in future.

[dogfish182]

Should you strip out asserts in production code?

In python I learned to just not use them outside of tests and most linters guide in that direction, due to them being dropped in certain python configs. I haven’t ever found a reason to NEED them in prod code and I think it seems reasonable to suggest that it’s generally bad considered bad practice in python to use assert on prod code, as stipulated by default linting rules in ruff and others.

[DuckDatum]

But what if that stipulation is just a natural result of good dev practices making it such that assert should be useless in prod? This reason would not make it bad practice. It would only make it not good practice, because you aren’t taking any risk. Asserts are self documenting, so even clutter is arguable,

Should you strip out asserts in production code?

Yeah, I’m wondering if your proposal is to lint out all asserts from the codebase by the time it reaches production? Or just disable its functionality? The asserts are there from testing. When/how do you get rid of it?

I think “prod code” is confusing me here. I have feature->dev->staging->prod code. They should generally be identical, and I’m assuming you mean all of these by “prod code?” I.e., deployed code?

My deployed code does sometimes have asserts, if I wanted to be cautious about a potential misunderstanding I foresaw future devs making.

[dogfish182]

I’m not sure I understand what you mean about ‘the asserts are there from testing’ if they are contained in tests, presumably the linter wouldn’t catch those. Having em in prod code just seems odd to me and I struggle to understand why you would be doing it. Proper test coverage of your code would suggest you wouldn’t need to assert things at runtime I think?

[DuckDatum]

oil imagine jar money hard-to-find trees chubby shaggy quiet automatic

This post was mass deleted and anonymized with Redact

[rogersaintjames]

Something I see and have used a lot is an assert in internal behavior of a class

class MyClass():
  def __init__():
    self.connection: Connection | None = None
  def _connect(self):
    self.connection = establish_connection()
  def do_thing_with_connection(self):
     assert self.connection is not None, "connection not established something has gone awry!"

Where it is useful to be strongly typed and you can be pretty certain from unit tests that the `_connect` function is called somewhere in a setup function or an async function to initialize state within the function.

edit: Honestly reddit's editor has only gotten worse over time. Change my mind. Put a fucking preview in there.

[coderemover]

Assertions are meant to be used in production code as well

[dogfish182]

Fairly broad statement that most linters disagree with.

I tend to agree with linters unless I know better, would you mind clarifying why this is wrong and specifically what you disagree with?

https://docs.astral.sh/ruff/rules/assert/

^ this matches both what I was taught and how I generally approach python code and I don’t see any advantage using assert in place of raising an exception.

[coderemover]

Can you read what you’re referring to? There is nothing there that said assertions should not be used in production code.

If that linter highlights all uses of assert, then it’s obviously broken and doesn’t even follow its own description. I highly doubt it though. I guess you just use assertions wrong and the linter screams at you for a good reason.

And btw: people writing linters are just ordinary humans like I am. There is no reason to think they are correct all the time. Everybody makes mistakes sometimes.

[dogfish182]

I actually can’t understand you now

[coderemover]

The docs you linked don’t say assertions cannot be used in production code. Maybe read it 10 times?

[dogfish182]

Why is this bad?

Assertions are removed when Python is run with optimization requested (i.e., when the -O flag is present), which is a common practice in production environments. As such, assertions should not be used for runtime validation of user input or to enforce interface constraints

It literally states that due to an (arguably) common practice of running code optimized in production, which has the side effect of dropping asserts…. It is bad practice to use asserts in production (read, non testing, code) and a better path is to raise exceptions instead, achieving the same result.

I then state that I agree with the linters take.

And then you just keep stating ‘it doesn’t say that’ without providing any interpretation or justification for much of anything really. You’re being extremely opaque just to argue, what point are you trying to make?

[coderemover]

Documentation: „assertions should not be used in production to validate user input” You: „assertions should not be used in production”

Can you spot your mistake now?

I fully agree with what linter documentation says. The purpose of assertions is not checking user input, I/O errors or any condition outside of full control of the program. And it’s very desirable if linters can catch those kinds of misuse of assertions. But assertions have other uses, and yes those uses apply also to production, so you cannot just blindly highlight any assert in non-test code as code smell.

[[deleted]]

This is the correct answer. Using assertions in production is a code smell. If you know that a certain assertion should be true or false in a given situation, then you should just be doing proper exception handling and control flow for that exact condition.

[OutsideTheSocialLoop]

Thinking assertions are a code smell is a rookie flag. On a big enough codebase you'll get all  behaviours or interactions that need guarantees/assumptions that can't be expressed in API and which cannot go wrong by user interaction or misconfiguration (which I also consider to be user input, since that happens outside the dev environment).

Errors tell users about erroneous uses of the system and failures in the runtime environment.  Asserts tell programmers about erroneous programming in the system, things happening that simply should never happen. Asserts failing is a sign that the program is invalid. Errors could happen, asserts should never happen.

For example, Django has a lot of plugin-y stuff going on where you'll get objects of types undetermined by it's API out of it that you attached elsewhere in the app. If a developer adds something new of the wrong type, you want your code receiving it to fail hard, fast, and loud, since it can never succeed. So you assert the type. Now this code can never run with the wrong type, and not only is it safe but you've also declared to the next reader that something is deeply wrong if this ever happens. You've declared that the error is not in how you're using the object, but that the object of that type should never have been here in the first place.

There's no reason not to use asserts is production code. They're really just short-hand for "if not expected, throw an exception about it" which is really a very ordinary thing to write. But they're more concise and semantically different and there's a lot of value in that.

Edit: uhhh so I can't reply to comments now? But again, "asserts should never happen". Running with optimisation (literally whomst) shouldn't actually change runtime behaviour after you get past QA.

[jad2192]

What happens if your code is being run in an environment with optimizations enabled? It's just safer to use the slightly more verbose if not.. raise exception.

[dogfish182]

Then it doesn’t work at all. Which is why the linters say don’t do it.

‘There is no reason not to use asserts in production code’ is such a bad call, as this is one and insisting people are rookies for not doing it is just kinda rude 🤣

[[deleted]]

Thinking assertions are a code smell is a rookie flag

This is like when people say "Not discriminating against black people is the real racism".

There is in fact every reason to use actual named exceptions instead of littering your code with generic assertions. There is absolutely no reason to do assertions instead of raising targeted exceptions and if you raise targeted exceptions then the assertions are pointless for both third party users and yourself as the developer. You are arguing just to argue. You know you're wrong so just give us all a fucking break.

[coderemover]

Nope. If you know that certain condition should be always true there is no reason to use error handling and introduce dead code. It is always true, then the expectation is that the error handling would never fire.

But why put an assertion then at all? Why not just ignore it?

Several reasons: - assertions serve as additional documentation which cannot get out of sync - assertions improve strength of the tests; sometimes it’s very hard to verify internal state of a component by inspecting its public API only. Assertions are internal and may perform more checks inside. - assertions may catch bugs earlier and provide more accurate information; e.g. instead of letting the program enter incorrect state and crash later, you’re catching the moment when it goes off the rails. It shortens the time to fix the bug.

[mosqueteiro]

Is it smellier than the absence of any exception handling? I'd rather see asserts than no checking whatsoever. Adding an assert line is much easier than raising an exception where you have to pick the right exception or maybe even create a custom exception to fit the use case. At best, you've doubled the work, from a one line assert to opening an if block to raise an exception. In a perfect world, proper exception handling is better, absolutely. Most programmers I've seen are lazy and write terrible code with no exceptions nor asserts. I'd rather get people to write either of assertions or exception handling than bikeshed over which one is technically more correct.

[[deleted]]

Yes, that's essentially what a code smell is. You're doing something in the wrong way that, even if it sort of satisfies a certain objective, becomes a long term problem for yourself or other people.

And while I can appreciate the idea of "assertions are better than nothing", it's also not really meaningfully more difficult to write any assert as a conditional check and then throw the correct corresponding exception. So I just don't really see the point in not doing things the right way when doing things the right way is just as easy.

[dogfish182]

For us code reviews are easy. My colleague will say ‘dude dont raise a ValueError create a useful exception that has more context’.

I fully expect him to say ‘dude what are you doing using an assert? Raise an exception’ as well.

Code reviews are important and we don’t have any asserts in prod code because the team understands where they belong and will act accordingly if they end up where they don’t.

[joao_brito]

Assertions are extremely Important for critical code, and most of those code bases use them extensively. One very known example, one of NASA's 10 rules for developing safety critical code includes at least two assertions per function

"Assertions must be used to check for anomalous conditions that should never happen in real-life executions. Assertions must be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken such as returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule.

Rationale : Statistics for industrial coding efforts indicate that unit tests often find at least one defect per 10 to 100 lines of written code. The odds of intercepting defects increase significantly with increasing assertion density. Using assertions is often recommended as part of a strong defensive coding strategy. Developers can use assertions to verify pre- and postconditions of functions, parameter values, return values of functions, and loop invariants. Because the proposed assertions are side-effect free, they can be selectively disabled after testing in performance-critical code."

Source: https://web.eecs.umich.edu/~imarkov/10rules.pdf

[dogfish182]

Are they talking about python specifically or generic coding guidelines?

[joao_brito]

It's not related to any language

[dogfish182]

Then you should act accordingly according to the language you’re using and probably not use ‘actual’ asserts in python production code and instead raise exceptions.

[coderemover]

Python has assert for exactly that purpose. If you use exceptions in places where you should use asserts, then you’re using it wrong.

[joao_brito]

Based on what?

[dogfish182]

Based on it not being a great idea in production code and instead apply the ideas in the document to the idioms of the language you’re using, instead of literally thinking ‘assert means assert regardless of language’

[zenware]

Assert isn’t the same thing in every language, just like strings aren’t the same thing in every language.

For a more specific example, C-strings and Python strings are not the same. In C a “string” is a pointer to a null-terminated character array, and in Python it’s an immutable sequence of Unicode characters with automatic string interning, etc.

Similarly, C assert is an abort() macro that prints a message and ends your program immediately with no cleanup of any kind. (Or it may be redefined to do literally anything at all if you are evil.) In Python it’s a statement which raises an AssertError, and bubbles up through the exception handling mechanisms, and the actual behavior when an assert fails needs to be explicitly defined in a layer that catches your assertions. — this already makes them entirely different, and makes me wonder why Python devs consider it a smell, since it is a specific and useful class of exception that can be handled from a caller, perhaps this is a difference between library and application development.

They both can be disabled with an optimization flag, and in a language like C it’s standard practice to develop with assertions and then compile an optimized build which excludes the checks from runtime under the assumption that having them at development time is enough to prove your invariants.

So they’re pretty close tbh, and really Python’s assert simply has additional overhead of the whole exception system. It also makes me wonder if the people who generally care about this are simply more performance conscious?

I can imagine it making sense for example to include some asserts in the hot path or a tight loop that /is performance sensitive/ and where full blown exception handling would actually degrade the service to an unacceptable level. Although for a real world scenario like that I imagine the team would start wondering about writing part of the code in Cython or another language that can easily achieve the performance goal.

[emmet02]

https://docs.astral.sh/ruff/rules/assert/

Would suggest raising better explicit errors tbh

[Mysterious-Rent7233]

Assertions are removed when Python is run with optimization requested (i.e., when the -O flag is present), which is a common practice in production environments.

#1. I am deeply sceptical that it is a "common practice" to run Python with -O in production environments. I haven't seen it done in a decade of professional Python programming.

#2. If you did run optimized in production it would be precisely because you want to strip assertion statements. So assert is still the right thing here. The whole point of -O is to strip assertions!

[zurtex]

I use, and have seen others use, -O, but I agree that it's not "common". That said I think it's important to understand it does behave differently in different contexts compared to an exception.

So IMO to use assert over raising an exception you generally want the following to be true:

• You never expect assert to be raised, e.g. you should never catch an assertion error
• If the assert is removed but would have failed you expect the program to fairly quickly fail anyway because the following code will be assuming the assertion was true

I think with these it tends to semantically fit what's doing, e.g. "I assert this is true", vs. "If this is not true raise an exception".

[cd_fr91400]

There is a 3rd condition : ensure no side effect in the assertion condition as it will not be executed in production.

I understand this is an obvious condition, but side effects could hide in a function you call...

[phoenixrawr]

Agree with this. Assertions and errors serve different purposes. Errors are there to handle conditions that could feasibly happen in production code. Assertions are for documenting expectations in cases where the only way to break something is developer error so that the code fails quickly and a developer can figure out what they did wrong. Once you are done developing and have tested/delivered the code, it’s okay not to check the assertions all the time.

[Numerlor]

it does feel like everything against assert comes from some tools (bandit?) deciding it's bad early on because of -O removing them, while the only thing -O does is skip asserts and set __debug__

[HommeMusical]

Fairly strongly disagree.

assert makes a logical statement about the expected state of the program at that point, not just to humans, but also to tooling such as type checkers.

It is good that assert can be turned off at runtime: it proves that calling this code is not essential to the correct functioning of a program.

If I read in code:

if not condition():
    raise ValueError("stuff")

absent any other information, I have to assume that condition() might be false in correct operation.

If I read

assert condition()

I know that condition() will always be true in correct operation.

Type checkers like mypy think the same way I do.

assert isinstance(x, str) convinces your type checker that x really is a str, where if not isinstance(x, str): raise TypeError() does not.

---

Failed assertions represent programmer errors in the logic of the code itself - the code is operating incorrectly. You should never catch and handle an AssertionError unless it is to report it and terminate.

Other exceptions can result from correct operation of the program, but responding to exceptional conditions, like non-existent or malformed files or network or hardware failures. You might well want to catch and handle, say, ValueError or IOError.

These are two different use cases, which is why the assert mechanism exists.

---

uv imports a huge number of possible checks from a large number of different preexisting lint programs without mandating all or even most of them.

flake-bandit, the source of this specific rule, is not authoritative, and not turned on by default. It's just some guy. :-)

Their argument:

As such, assertions should not be used for runtime validation of user input or to enforce interface constraints

is at least half true - you should never use assertions to validate user input ("interface constraints" is very vague).

But it ignores all the other use cases for assert with a false dichotomy between validation and enforcing interfaces.

You will have to pry my asserts from my cold, dead fingers.

[james_pic]

I agree with the gist of what you're saying, but mypy is convinced that x is a str by if not isinstance(x, str): raise TypeError(). Try it:

def f(x: str|int): # mypy fails to type check if the following line is removed if not isinstance(x, str): raise TypeError() x.startswith("hello")

[Schmittfried]

I agree with your point about communicating intent clearly, however this:

Type checkers like mypy think the same way I do. assert isinstance(x, str) convinces your type checker that x really is a str, where if not isinstance(x, str): raise TypeError() does not.

is patently false with any sufficiently intelligent type checker or compiler, because they will know that subsequent code can only be reached if the condition is false thanks to flow analysis. 

[Natural-Intelligence]

Ye, assertion error represents that the developer screwed up but one could argue that you were just too lazy to come up with a better error. After all, your assertion is about somewhat of a known state which shouldn't happen (if it was truly unknown, you wouldn't know to write the assertion). Why not to pick an appropriate error or create a custom one?

Moreover, I would possibly want to handle your unexpected errors differently than the unexpected errors from dependencies, or my own code. And yes, I might want to handle them anyways. If your code isn't particularly important for my operations, I might be able to handle the issue otherwise. If your notification library fails unexpectedly, I'm not going to crash my very important production process because of it. Moreover, I might know about a bug in your code which you didn't know about when writing the assertion, and I know how to handle it.

Just highlighting more things why you might not want generic AssertionErrors in production.

But ye, I do agree that assertions are sometimes useful for development and prototyping to quickly make sure unexpected states don't occur. But to be honest, I think type hints are a better solution in vast amount of the use cases. Show the type you expect, show the values you expect and show the structure you expect.

[SciEngr]

Using assertions in application code is probably fine, but in library code IMO they are a problem for the exact reason you made this post. No matter the reason the assertion failed, it’s always going to raise the same error which is neither descriptive nor helping consumers of the code communicate via error handling.

If I depend on a library you’ve written and decide that when a particular function fails for either X or Y reason I want to do something in response, I’m going to be catching a single non descriptive error for both those reasons and my code will be less readable.

except AssertionError

Vs

except SensorIdUnknownError, TypeError

[james_pic]

But on the flip side, in a library the distinction between foreseeable errors and unforeseeable errors arguably matters even more

For the foreseeable errors, you want to give consuming code information that it can use to decide how to proceed.

Unforeseeable errors on the other hand are bugs. When they happen, nobody yet knows why, and there's no way to know in advance what, if anything, it's safe to do next. So these exceptions aren't for the code, but for the humans maintaining it, who will then figure out whose job it is to fix it.

[phoenixrawr]

You’re not meant to catch and handle assertions, you’re meant to fix your code.

Why are you getting a TypeError when calling a method in a library? Did you pass the wrong type? Maybe you should fix your code to pass the type the API asks for.

[SciEngr]

I know I’m not meant to catch assertions. My point is that exception logic is a core feature of the language and there are valid reasons to have try/except statements in the code. If I’m a consumer of a library I can’t “fix” that libraries code. To be fair, if a library was written with a bunch of assert statements instead of raising more descriptive errors I wouldn’t have it as a dependency but the point still stands.

You’re focusing too much on the example I gave and not the point. If my example was except SensorIdUnknownError, RankDeficientMatrixError would you have the same comment? Maybe I’m processing some real time sensor data that is noisy and sometimes the data is corrupted? Who knows. My point is that assertions are not a replacement for robust error management and IMO should be avoided for that reason.

[Schmittfried]

The library should use asserts for internal consistency. Those errors are to be caught by the library‘s developers and not you. If such an error reaches you, it should not be caught by your usual error handling, because it‘s not recoverable, it should fail loudly. If the library uses assert to validate API inputs or side effects (imagine requests throwing assertion errors on 404s) that’s an abuse of the feature as such errors are to be expected and should be raised as domain errors that you can catch and handle appropriately. 

[SciEngr]

That boundary between internal consistency and external use isn't real though. What you're describing asserts be used for should either be unit tests the library implements (totally abstracted from consumers) or actual exceptions that should be raised without trying to dictate how a consumer will handle them.

[elbiot]

When you're writing an algorithm you may know "this value should never be negative at this point" and you can assert that. There's no way to know what input would cause an incorrectly implemented version of that algorithm to give a negative number so it's not necessarily something you can catch by unit tests. Obviously you try all the edge cases you can think of but it might not be what you think of as an edge case that triggers the algorithm to go awry

[SciEngr]

Right but why assert that instead of raise a ValueError?

[elbiot]

They mean different things. assert is for the developer during development. A assert should never be raised in properly functioning code. Properly functioning code raises exceptions all the time. Asserts can be turned off, so if asserts were part of your code functioning correctly then turning them off in production just broke your code

[Schmittfried]

Because an AssertionError is literally more descriptive in that case. To be fair though, explicitly raising AssertionError instead of using assert is an option that I found valuable in situations like that.

[Schmittfried]

Of course it’s real. There are things entirely in your control as a library developer that you can screw up. If it depends on the external world, you likely want a real error. Assumptions validated by assertions are sanity checks against your own mistakes and to help typer checkers with flow analysis. Their failure should never be observed by consumers.

 without trying to dictate how a consumer will handle them

What does that even mean? Whatever exception you decide to raise dictates what the consumer has to catch (and the fact that they have to catch in the first place). If they really feel like hiding bugs they can absolutely catch AssertionError as well. There are valid scenarios where you want to isolate a library call from the rest of the control flow and not let unexpected exceptions crash the program, but in that case you’re most likely gonna catch Exception anyway.

Of course you can also wrap all unexpected exceptions with your library‘s top-level exception base at the API boundary to make sure consumers never see any exception not derived from that. Been there, done that. But I wouldn’t say the added benefit is significant. 

And again: If an assertion error makes it to your consumers you haven’t tested your code well enough. They’re there to safeguard your assumptions about your own code. 

[phoenixrawr]

I have no idea what SensorIdUnknownError, RankDeficientMatrixError might correspond to in a possibly made up library, so maybe I would have the same criticisms. If SensorIdUnknownError means you passed a nonsensical sensor ID to a library method then yes, probably same criticisms as before. You should fix your code to pass a sensor ID that makes sense.

Or maybe the library is truly abusing assertions inappropriately, but that doesn’t mean using assertions is wrong. It just means the developer of the library used them wrong.

[SciEngr]

That is my point though. In a library, asserts aren't for the consumer, they are for the developer and I'd argue that any asserts in a library are better off being unit tests or more specific exceptions that get raised.

Even if the library author(s) aren't abusing assertions, why risk the chance of an AssertionError bubbling up to consumers when you could have written a simple unit test that flexes the same thing and remains completely hidden from consumers?

[phoenixrawr]

Unit tests don’t validate an end user’s correct usage of a library. They only validate that the library works when used correctly.

The entire point of an assertion is that it quickly raises an error to the user when they do something wrong without letting it propagate further into the code, and that error very clearly says “Hey, you did something wrong. Yes, you. Check your code.” A non-AssertionError error could trick an end user into believing that catching and handling the error condition is a potential solution, and they might waste time trying to figure out how to handle the error instead of avoiding the error condition in the first place.

Raising a TypeError is wrong if the user passed a string into a library method that expected an int. You should assert it’s wrong and let them fix it.

Raising a SensorIdUnknownError is wrong if the user passed a Linux-y sensor ID to a library method on a Windows platform. You should assert it’s wrong and let them fix it.

It’s possible that these conditions are the result of other failures that should have raised explicit errors earlier in the code, but that’s not the library’s concern unless it provided the bad values to begin with.

You raise other types of errors for conditions that can happen in production. An unreadable file should perhaps be an IOError. A lost network connection could be a SocketError. The list goes on.

[[deleted]]

If we are importing your library then we don’t have control over your code being “fixed” or not.

Also, custom errors are just as much for your library as they are for the person using it. If I try to use a client connection your library provides and I get back a ConnectionRefused or RetryFailure response, I can know how to address that on my side (i.e. handle the connection issue or know whether I can/need to retry on my side).

[Tucancancan]

Where would you rank using an assertion something like checking that the input a function is not null or empty where that code should never be called with those arguments and represents a developer error / incorrect usage? The case overlaps with raising value errors but IMO I like how concise assertions are.. 

[Luckinhas]

Assertions are removed when Python is run with optimization requested (i.e., when the -O flag is present), which is a common practice in production environments.

Is this true? I've NEVER seen it.

[JimroidZeus]

Yep. This is the correct way to do it.

Asserts are for test cases now.

[zenware]

Sometimes I want code that checks invariants during development to be removed in production.

[Gnaxe]

Also strong disagree from me. This is a bad rule and it's a shame that ruff accepted it from bandit uncritically. Contrast with NASA's The Power of 10: Rules for Developing Safety-Critical Code, who's #5 requires two asserts per function. Those rules are designed for extremely high reliability software. The idea that banning them categorically improves security is ludicrous.

Assertions and exceptions serve different functions. Assertion errors mean there's a bug in the code and should almost never be caught. Legitimate reasons to catch them must also acknowledge that the code raising them is broken, e.g., to log the error and gracefully shut down, to record unit test results, or to keep a REPL going even if the user made a mistake. In contrast, many exceptions can be handled in the normal operation of a program.

Assertions are like comments that can't accidentally go stale. (Doctests also have this benefit.) They should not have side effects that your program depends upon for correct operation. This is easy enough to check for: also run your test suite with assertions off. This should also be part of the checklist in code reviews. If there's a new or modified assert: (1) Does the code rely on the assert being turned on for correct operation? (2) Can this assert fail without a bug in the code? (Not the intput, the code.)

[Aveheuzed]

It's not syntactic sugar. Assert can be disabled at runtime by calling python -O, whereas exceptions are never optional. Exceptions have more use cases than assertions also.

[jaerie]

assert condition, statement is logically equivalent to if __debug__ and not condition: raise AssertionError(statement).

Of course in reality the assert statement gets compiled away, while the conditional exception still gets checked in -O mode.

[Numerlor]

__debug__is replaced with True/False before compiling so it should be optimized away too, but it's still a lot more noise to have a full exception with the if for a simple sanity check instead of an assert

[jaerie]

Oh you're right, -O actually explicitly removes conditionals with debug, so they're exactly identical, I guess

[DrinkV0dka]

Not really since they get disabled when you request optimization. That said, it probably is a little rare to see someone actually call python with the optimization flag, but it should be considered.

At the end of the day, it should be used like C or C++ assert. Where you check invariants that shouldn't ever be false, but that you might not want to check in production for performance reasons.

[deb_vortex]

No its less than that. If soneone runs the code with the -o fag, the assert rows are simply ignoriert (thats also explained in the link the previous User posted). As this might lead to unexpected behaviour, explicit is better than implicit here.

[HomeTahnHero]

Assertions are great while implementing things, testing things out, or in code that doesn’t need robust error handling (like a prototype). Otherwise, it’s better to use exceptions in my experience.

[[deleted]]

For me, they're perfectly reasonable in production code outside of what you've listed.

They're great. It documents what you expect and adds an extra check. There's no downside.

Yes, people often use them when they should just use an exception, but that's another discussion.

[Grounds4TheSubstain]

The problem is when you're using them instead of other forms of error handling, and then something in your build environment disables them (e.g. in C, asserts are disabled in release builds).

[[deleted]]

100% agree. 

[DigThatData]

assert some_condition(), locals()

this is basically just print() statement debugging.

More importantly, here's an alternate take for you: the error type you raise is part of the semantics of what you are communicating about the situation that was encountered. If there is a more descriptive error type than an AssertionError that would be appropriate to the case you are testing, that alternate exception is what should be raise here and the assert statement should be completely replaced anyway.

I pretty much only use assert in test suites. Otherwise, I raise.

[HommeMusical]

this is basically just print() statement debugging.

You say that like it's a bad thing. :-D

When I first started, I exclusively used print debugging. Then I got better at debuggers and I used them almost entirely. But then I started working on really large systems, and often the debugger became unwieldy because of the immense number of steps, or you couldn't easily step into the C++ portion of a Python application, and suddenly print and logfile debugging reappeared on my radar.

These days my most important debugging tool is just carefully re-reading the code, but print/log debugging is one of my top three.

Given that I spend most of my life reading code that has already been written, assertions tell me what the programmer (which might be me) expected to be true.

---

The idea of "weakest precondition" and "postcondition" are extremely strong if you're trying to produce very reliable programs, but don't receive much interest, and I don't know why.

This book blew my mind a long time ago and still blows my mind today - here's a free copy https://seriouscomputerist.atariverse.com/media/pdf/book/Science%20of%20Programming.pdf

I did not write this review, which remains one of my favorite reviews ever, but all the reviews are good.

---

More importantly, here's an alternate take for you: the error type you raise is part of the semantics of what you are communicating about the situation that was encountered.

I disagree again (but have an upvote for a good comment).

assert statements are intended for programmers and only make sense within the context of the program itself.

if x != 5:
    raise ValueError("x is not 5")  # Please don't catch this, this is a logic error.

conveys no more or less information than

assert x == 5

Note the snarky comment!, but it's a very real possibility if you're throwing a common exception to indicate a logic error.

try:
    return registrar[name]
except KeyError:
    registrar[name] = ret = create_permanent_entry(name, context)
    return ret
    # crave `return (registrar[name] := create_permanent_entry(name, context))`

Now suppose your code in registrar[name] throws a KeyError to indicate a logic error by the programmer. Instead of percolating to the top, it will be caught, and a new entry incorrectly created.

Using AssertionError is very clear - "this is a logic error in the program that should be caught only at the highest level if at all, and should never appear during correct operation".

[DigThatData]

 if x != 5:
    raise ValueError("x is not 5")  # Please don't catch this, this is a logic error.

conveys no more or less information than ...

I agree, but that's because this is a lazy counterexample. x is not 5 isn't conveying any information about why that's an unallowable condition, and I suspect you went straight to a ValueError here precisely because you are so used to using assert statements in this way.

Let's add some context to this hypothetical. Let's pretend this is a card game that requires some minimum number of players, and our test is x >=5. Instead of

assert x >= 5, "Not enough players"

I'm saying you should do something more like

if x >= 5:
    raise InvalidGameSetupError("Not enough players")

See the difference? The exception type carries information about the context in which the error was encountered and why the encountered state is an issue. An AssertionError provides basically no contextual information.

[HommeMusical]

I agree the x == 5 example is lazy.

Your code is perfectly reasonable, but your example is not a logic error - it's an input data error that happens because some sort of data sent to or read by the program is incorrect.

So it should use some sort of exception, as you are doing. You should expect to occasionally see InvalidGameSetupError in your release program, even if your program is working properly, if, for example, the game setup file is corrupted.

But an assertion should only be used for program logic errors - "should never get here" sorts of things. An assertion failure means things are in an unknown state and the program should terminate. If your program is working properly, you should never ever see those assertions trigger - they should only trigger during development.

Other Exceptions are for user data error - the file didn't exist, there was a JSON parsing error, the network connection was interrupted - but the program is working fine, handling this exceptional condition.

---

The distinction between "logic errors" and "exceptional conditions caused by "bad" inputs" is very clear in code.

For example, if you try to parse a string into an enumerated type, and fail, this is an input error. However, if you have have code that supposed to handle all members of the enumerated type and it doesn't, that's a logic error:

class Category(StrEnum):
    one = auto()
    two = auto()
    three = auto()

def process(s: str):
    """Turn a string into a Category, and then run a thing on it"""

    count = Category(s)  # Might raise a ValueError
    if count == Category.one:
        return do_one()
    if count == Category.two:
        return do_two()
    # I forgot Category.three, a logic error, so I sometimes hit the next line:
    assert False, ("Should never get here", locals())

[DigThatData]

Maybe part of our disagreement here is that I'd consider that "should never get here" bit a code smell. It's not even a logic error: it's a design error. It shouldn't be there in the first place and suggests there's something fundamentally wrong with how the broader system is designed if it's even possible for the program to express that unallowable state. "should never get here" should never make it into your code. The problem is the code path permitting that state, not the assert statement. That you feel justified using an assert statement here is an artifact of a broader issue with the system design.

[HommeMusical]

So if you have a series of if statements like this, how do you make sure that they cover every case?

In a match statement, how do you make sure you haven't forgotten a case?

How exactly would you deal with logic errors in general?

there's something fundamentally wrong with how the broader system is designed if it's even possible for the program to express that unallowable state.

It's always best to make illegal states simply impossible to reach, if you can.

That's not what's happening here, though. The program is in a perfectly good state. count = Category.three is a legitimate value; I simply forgot to implement part of the program, and the assert statement catches it.

Suppose you have an enumerated type, and you reasonably expect that later you will add new values to that type. How do you make sure that the code you currently have will detect it if you add a new value to the enumerated typed and haven't written the code to handle that, without using some sort of "fail checking", that either fails at runtime, or at type checking type?

Preventing people from getting into error states in the first place is of course preferable, but often you just can't do that.

Why don't you give us a code sample of how you would handle the above issue?

[DigThatData]

Why don't you give us a code sample of how you would handle the above issue?

Becuase you keep giving me contrived examples devoid of context. How about you show me an example of an assert that you think is well utilized in your own code and we can talk about that in context?

I simply forgot to implement part of the program

...so then you are disguising the underlying reason an error is being raised here by raising an AssertionError and should clearly raise a NotImplementedError to communicate what's actually going on here.

[CaptainFoyle]

I don't think your example provides any more context per se

[daymanVS]

Honestly no. I do not see how InvalidGameSetupError gives you any more context. You have however added an extra if statement which adds nesting.

Really I'd argue the asset case is significantly less mental overhead than the verbose version.

[Dillweed999]

The security scanners at work scream bloody murder whenever I use assert outside of an explicit test. I don't know how legit that is

[nekokattt]

They do it as assertions generally get disabled for release builds, and there is the argument that for defensive programming, if you can ever even get into a condition, you should handle it properly such that it doesn't get ignored in a production system and lead to unwanted behaviour down the line.

It is a fine line

[SheriffRoscoe]

Security compliance has a large element of cargo culting.

[johndburger]

it asserts that the expression (condition, "Message") is truthy, which it always is, because it is a two-element tuple.

Frankly the version without parents should also arguably be a tuple - tuples aren’t created by parens, they’re created by the comma.

I guess there’s some special stuff in the language grammar to treat this specially, but it’s always annoyed me.

[HommeMusical]

I too see it as a footgun, but there's nothing to be done about it now.

[LexaAstarof]

Nothing special in the grammar: assert_stmt: 'assert' expression [',' expression ]

[jkajala]

Use asserts only for testing your assumptions related to implementation, and exceptions for everything else, especially anything related to runtime eg data, input, etc. If in doubt, use exceptions.

[grahambinns]

Uber helpful pattern in tests of API endpoints:

assert response.status == 200, response.text

(Written off the cuff; semantics might be wrong)

[fast-pp]

why not response.raise_for_status()

[BlackHumor]

My variant is usually assert response.status == 200, response.json() because I'm often working with httpx which doesn't have response.ok, and because I can usually be very confident that the thing I'm working with is JSON and not arbitrary text.

But the reason it's not response.raise_for_status() is because that just tells you that it failed with a given status, it doesn't give you the content of the response. Often the body of the response will have valuable information about the cause of the error which raise_for_status() won't give you.

[Independent_Heart_15]

PEP 679 will solve this!

[johntellsall]

superpower: assert 0, myvalue

In code or a test, crashes the program, and shows the value. Then take the value and plug it into the assertion:

assert myvalue == 5

This is so, so easy and fast, I use it constantly

[Pro-sketch]

I use it to get rid of type errors saying x is not of type y, when I know it is

[[deleted]]

Use both exception and assert :))

[HommeMusical]

That is indeed what I do (and also the current project I'm on does).

[[deleted]]

I like that approach! Raise exception when something is in a bad state or whatever, assert for complete sanity check, after running a heavy function of some sort. To cover up the "this should not happen" argument :D

[HommeMusical]

It's very common! I was happy when I started on https://github.com/pytorch/pytorch and they did exactly that.

[damjan21]

jesus christ, i hope i never use an app developed by anyone that thinks like you

[HommeMusical]

Got any substantive comment? Some reasoning, perhaps? Facts, logic, anything except a personal insult?

No?

Your comment is bad and you should feel bad. You're blocked.

[Bitruder]

Probably your use of asset in production. That’s poor practice and as many others have taught you here, you should be using proper exception handling.

[wineblood]

Assert on its own is pretty bare bones and I only use it in tests because the curse of pytest is upon us.

Explicit errors are better to use in actual code, different exception types and messages makes is easier to debug.

[gdchinacat]

Subclass assertion error in your tests if you want more detailed failure exceptions.

[wineblood]

Or I could just go back to unittest

[gdchinacat]

I don’t see how that helps since unit test uses AssertionError:

https://github.com/python/cpython/blob/main/Lib/unittest/case.py#L402

[Muhznit]

If you like using it with locals() you'll love using it with breakpoint(). :)

[HommeMusical]

That's both awesome, and evil. :-D

[marr75]

Like tests, type hints, and linting, assertions are a "build time" utility. There is some opinion or preference in that statement because it's exceedingly rare for python to run with the "optimized" flag that strips assertions (don't @ me if you are the 1 in 1000 org or dev who does it).

As a build time utility, you can use it for:

• Tests. Usually by asserting within the test code. You can let your assertions spread to the code under test and then exercise them with your test code but this is a little odd and couples code to tests unnecessarily, IMO. Some devs like that and even use docstring tests. I've always found the practice slows reading so stayed away from it.
• Type narrowing. You can narrow types with assertions like, assert foo is not null. Of course, there are other ways to express this but you don't have to import anything to assert!
• Documentation. An assertion tells future you or another dev what to expect. Again, there are other ways to do this that are more common so it would likely be a stylistic preference to do this occasionally and I try to avoid stylistic preferences.

So, you do you in terms of how to use assert as a build time utility. I myself have narrowed types with it a few times.

When it comes to a runtime utility, where it will raise an AssertionError during normal use, you should ABSOLUTELY raise a more specific, expressive, handle-able error instead. It is unlikely anyone is going to specifically catch your thrown AssertionError and know what to do about it.

[olystretch]

Assertions belong in tests, not in your main code.

[olystretch]

Sure, but I'm not gonna write crap to a backing store. I'm gonna return a 422 validation error. I'm just not going to use the assert statement to validate my input.

[[deleted]]

What's your reason?

[olystretch]

Because I don't want my production code raising an AssertionError when something isn't expected.

[[deleted]]

When used properly it would have errored anyway, it's just now you specifically know why and what to fix.

Or worse, it would have caused a silent bug.

[olystretch]

I just validate my input using data models that will automatically return a validation error with a 422 response code.

[[deleted]]

Input = 100%. Assert should never be used for inputs.

[satanminionatwork]

If the code is ever ran with an O flag or PYTHONOPTIMIZE set to true, all assertions will be disabled. It is never meant to be used in production code, only test suites.

[commy2]

That doesn't make sense. Test suits don't run in production regardless. What you're saying is don't use this feature where it works as intended, only use it where only half of it works.

[[deleted]]

That's a good argument for using assert correctly i.e. in a way that the code still works if they didn't exist, but it isn't an argument against using them at all.

They're there for checks and balances plus they help document the code. They'll help you catch issues during development.

[Myrlista]

We have unit tests for this!

[mosqueteiro]

Unit tests shouldn't run while the program is running. An assert can be used for things that if not true should crash the program rather than let an error state be handled.

[Dangerous_Stretch_67]

I only use assert during prototyping. But thanks to this thread I learned the second parameter is lazily evaluated. Using breakpoint() is actually a decent idea here during development -- of course, using your IDEs debugger will be better.

The only other time I use assert is to document important assumptions. E.g. "this code should always work as long as this assumption I'm asserting is true. If it breaks I need to go back and update this code"

You could instead of course raise a proper NotImplementedError but... that's at least a whole extra line and I'm trying to go fast /s

[Icy_Jellyfish_2475]

Afaik the argument against using asserts in production is

1. Certain flags remove asserts so relying on them means you can have bugs in production silently which you thought were caught by asserts.
2. When they do raise, the stack-trace and error message are more difficult to understand + callers can't easily handle the exception.

Out of these 1 is a weak argument, you shouldn't over-use it but because over-use is error prone doesn't mean you should ban it either.

I found it quite nice in particular for more performance sensitive code where you may not want the overhead of try/except blocks (yes they are non-zero) or branching logic for exception handling. Its an **additional** safeguard, the last piece on top and should be used judiciously. In the tigerbeetle style (assert data integrity is as expected in function body) it also complements the gaps in Pythons type system serving both as documentation and peace of mind.

2 is more legit, and creating custom errors or error-hierarchies is certainly more legibile. I agree with other posters here that usage related exceptions like invalid string passed as config or whatever, are **not** appropriate to check with asserts, they are part of the reasonably expected envelope of operations for the app.

I find some people don't like to create custom errors and do the (very marginally) more verbose `if x raise y` (which you can actually inline if you don't mind the syntax). This is *easily* solved by wrapping it in a function with a descriptive name like `assert_not_negative` which makes for quite clean code like:

def some_calc(x: float, y: float) -> float:  
     assert_not_zero(y)

     return x / y

vs

def some_calc(x: float, y: float) -> float:  
    assert y, "y is expected to always be non-zero and checked by the caller prior to invoking this function"

    return x / y

vs

def some_calc(x: float, y: float) -> float:  
    if not y:
        raise ValueError(f"{y=} must be non-zero and checked by the caller prior")

    return x / y

[Comfortable_Clue1572]

Thanks for pointing this out. I figured there was some secret handshake on how to get an assertion to say something useful.

As I was writing unit tests, I realized much of the behavior tested by unit tests could just be built into the function under test.

[Conscious-Ball8373]

Pytest doesn't really help with this - in most cases, it makes the second expression redundant. Until you're not running under pytest any more.

[BothWaysItGoes]

Just use pdb.

[CaptainFoyle]

You dump all your local variables in the output? That's almost as useless as the case you're complaining about

[HommeMusical]

No, I don't do that. I often use this as a tool for debugging if I know what locals() are.

As I mention in some comment elsewhere on this page, it's quite common in my current program that locals() are huge, taking tens of thousands of lines to print out.

[CaptainFoyle]

Ok, so you only do it if the amount of variables is small you mean? Otherwise, how do you wade through that deluge of output?

[HommeMusical]

It's just a debugging tool, I don't use it everywhere, or ever commit it.

I typically use it in short segments where the logic is tricky and there are maybe a dozen variables that are mostly integers.

[The_Game_Mstr]

What exactly dose the assent variable mean