Introduction

This error usually appears when code copied from an older TensorFlow 1.x tutorial is run with TensorFlow 2.x. The fix is not to hunt for a missing import: in modern TensorFlow, eager execution is already enabled, so the old top-level function no longer exists.

Why the Attribute Is Missing

TensorFlow 1.x was built around graph execution. You defined operations first, then ran them later inside a session. Eager execution was added as an optional mode to make TensorFlow behave more like normal Python: expressions run immediately, values are available right away, and debugging is much simpler.

TensorFlow 2.x flipped the default. Eager mode is on from the start, and many 1.x setup calls were removed from the main tensorflow namespace. That is why this line fails in 2.x:

import tensorflow as tf

tf.enable_eager_execution()

If you are unsure which runtime you have, check it directly:

1import tensorflow as tf
2
3print("TensorFlow version:", tf.__version__)
4print("Eager enabled:", tf.executing_eagerly())

On a standard TensorFlow 2 installation, the second line prints True. In that case, there is nothing else to enable.

The Correct Fix in TensorFlow 2

For new code, delete the old enable_eager_execution call and write TensorFlow operations normally. You can inspect tensors immediately and use Python control flow without wrapping everything in a session.

1import tensorflow as tf
2
3x = tf.constant([1.0, 2.0, 3.0])
4y = tf.constant([4.0, 5.0, 6.0])
5z = x + y
6
7print(z)
8print(z.numpy())

The same applies to training code. In TensorFlow 2, the recommended low-level pattern is tf.GradientTape, which assumes eager execution:

1import tensorflow as tf
2
3w = tf.Variable(3.0)
4
5with tf.GradientTape() as tape:
6    loss = (w - 10.0) ** 2
7
8grad = tape.gradient(loss, w)
9print("loss:", float(loss))
10print("gradient:", float(grad))

This is the cleanest path when you control the codebase. Remove the outdated setup line, keep the rest of the code idiomatic, and avoid mixing 1.x session patterns into a 2.x project unless you truly need them.

Handling Legacy TensorFlow 1.x Code

Sometimes you are not starting from scratch. You may have an old notebook, a blog post, or an internal project that still depends on TensorFlow 1.x behavior. In that case, there are two reasonable options.

The first option is to use the compatibility namespace. TensorFlow 2 still exposes many 1.x APIs under tf.compat.v1:

1import tensorflow as tf
2
3tf.compat.v1.enable_eager_execution()
4
5a = tf.constant(5)
6b = tf.constant(7)
7print((a + b).numpy())

This call must happen very early, before the program creates graphs or tensors that lock execution mode. It is mainly useful when you are migrating code gradually, not as a long-term design.

The second option is to keep the code in graph mode on purpose if a legacy library requires it:

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5x = tf.compat.v1.placeholder(tf.float32)
6y = x * 2
7
8with tf.compat.v1.Session() as sess:
9    print(sess.run(y, feed_dict={x: 21.0}))

That pattern is valid for old projects, but it should be an explicit compatibility choice. New TensorFlow 2 code should not be written this way unless you have a specific migration constraint.

Common Pitfalls

The most common mistake is mixing documentation from different TensorFlow generations. A tutorial written for TensorFlow 1.12 can be technically correct for that release and still be wrong for TensorFlow 2.16. Check the version first before copying setup code.

Another frequent problem is trying to switch execution mode halfway through a notebook. Restarting the kernel is often required after changing eager or graph settings, because TensorFlow initialization state is process-wide.

It is also easy to assume the compatibility path is harmless forever. It is useful during migration, but code that leans heavily on tf.compat.v1 usually becomes harder to maintain. If you are already on TensorFlow 2, prefer converting training loops, metrics, and model code to native 2.x patterns.

Summary

• 'tf.enable_eager_execution() belongs to TensorFlow 1.x, not modern TensorFlow 2.x.'
• In TensorFlow 2, eager execution is already enabled by default.
• Use tf.executing_eagerly() to confirm the current runtime mode.
• For legacy migrations, tf.compat.v1.enable_eager_execution() can help if called early.
• Prefer native TensorFlow 2 patterns such as tf.GradientTape instead of carrying old session-based code forward.