Introduction

Yes, tf.cond can work with TensorFlow operations that have side effects, but the important qualifier is "TensorFlow operations." It is much less reliable to think in terms of ordinary Python side effects inside traced TensorFlow code.

What Counts as a Side Effect

In TensorFlow, side effects usually mean stateful ops such as:

• 'tf.Variable.assign'
• 'tf.Variable.assign_add'
• 'tf.print'
• queue or dataset save operations

These are TensorFlow graph operations, not just Python statements. tf.cond can route them because they exist in the graph.

Basic Example with a Variable Update

1import tensorflow as tf
2
3counter = tf.Variable(0)
4
5@tf.function
6def update_counter(flag):
7    return tf.cond(
8        flag,
9        lambda: counter.assign_add(1),
10        lambda: counter.assign_sub(1),
11    )
12
13print(update_counter(tf.constant(True)).numpy())
14print(update_counter(tf.constant(False)).numpy())
15print(counter.numpy())

This works because both branches return compatible TensorFlow results.

TensorFlow Side Effects Versus Python Side Effects

This is the main source of confusion.

TensorFlow side effect:

tf.print("hello from graph")

Python side effect:

print("hello from Python")

Inside a tf.function, Python print runs when tracing happens, not necessarily every time the graph executes. tf.print, on the other hand, is a TensorFlow op and participates in graph execution.

So the practical answer is:

• yes for TensorFlow-side stateful ops
• do not rely on Python-side effects as graph execution behavior

Only the Selected Branch Controls Its Branch Ops

tf.cond controls the work inside the branch functions. Operations created outside the branch functions are not conditionally protected by the branch itself.

1@tf.function
2def example(x, y):
3    z = x * y
4    return tf.cond(
5        x < y,
6        lambda: z + 1,
7        lambda: y - 1,
8    )

The multiply that creates z sits outside the branches, so it exists regardless of which branch is chosen.

If an effect should be conditional, place it inside the branch closure.

Branch Structure Must Match

Both branches of tf.cond must return compatible structures and dtypes. This matters even more with side effects, because it is easy to write one branch that returns a tensor and another that returns nothing useful.

A safe pattern is:

• perform the side effect
• return a tensor from both branches

1@tf.function
2def maybe_log(flag, x):
3    return tf.cond(
4        flag,
5        lambda: (tf.print("positive branch", x), x + 1)[1],
6        lambda: x - 1,
7    )

Prefer Explicit Returns Over Hidden Mutation

Even when side effects are allowed, TensorFlow code is easier to reason about when branches return the values you care about explicitly. Use mutation only when state change is truly part of the design.

That keeps control-flow code easier to test and debug.

Common Pitfalls

The biggest mistake is assuming Python side effects inside tf.function behave like TensorFlow ops. They do not.

Another mistake is placing work outside the branch functions and expecting tf.cond to make it conditional. Only work inside the branch closures is controlled by the predicate.

People also forget that both branches must return compatible structures. Mismatched outputs will fail tracing.

Finally, do not build logic that depends entirely on hidden side effects when returning a tensor explicitly would be simpler.

Also remember that stateful ops inside branches still need to make semantic sense for repeated graph execution. A branch that mutates variables on every call is valid, but it should be intentional and easy to reason about.

Summary

• 'tf.cond can support TensorFlow ops with side effects such as variable updates and tf.print.'
• It is not a good model for ordinary Python side effects inside traced graph code.
• Only operations inside the chosen branch function are conditionally executed by tf.cond.
• Keep branch return structures compatible.
• Prefer explicit returned values over hidden mutation whenever possible.