Introduction

If you see AttributeError: module 'tensorflow' has no attribute 'enable_eager_execution', you are usually running TensorFlow 2 code with a TensorFlow 1 tutorial in mind. The fix is not to search for a replacement at the top level, but to understand that eager execution is already on by default in TensorFlow 2.

Why the Error Happens

In TensorFlow 1.x, many programs built graphs first and executed them later in a session. Eager execution was introduced as an opt-in feature, so older examples often started with tf.enable_eager_execution().

In TensorFlow 2.x, the default model changed:

• eager execution is already enabled
• sessions are no longer the normal way to run code
• the old top-level API is gone

So code like this fails on current TensorFlow releases:

import tensorflow as tf

tf.enable_eager_execution()

The attribute is missing because the public top-level function was removed from normal TF2 usage.

The Correct Fix in TensorFlow 2

If you are writing normal TensorFlow 2 code, remove the call entirely and just run operations directly.

1import tensorflow as tf
2
3print(tf.executing_eagerly())
4
5x = tf.constant([1.0, 2.0, 3.0])
6y = tf.square(x)
7print(y.numpy())

That is the intended programming model. There is nothing extra to enable.

If you want a quick sanity check, tf.executing_eagerly() should return True in normal top-level TF2 code.

What to Do With Legacy TensorFlow 1 Style Code

Sometimes you are not writing new code; you are trying to run an old notebook or tutorial. In that case you have two realistic options.

The first option is to migrate the code to native TensorFlow 2 style and remove the old call.

The second option is to use the compatibility namespace:

1import tensorflow as tf
2
3tf.compat.v1.enable_eager_execution()
4
5x = tf.constant(21)
6print((x * 2).numpy())

That compatibility API exists for migration, but it comes with an important rule: it must run very early, before code creates graphs or uses APIs that depend on graph mode. It is a bridge for legacy code, not the preferred entry point for new projects.

Confusion Caused by tf.function

A separate source of confusion is that developers remove the failing call, then later notice behavior that still looks "non-eager." The reason is often tf.function.

In TensorFlow 2, eager execution is the default outer mode, but a function decorated with tf.function is traced into a graph for performance. That means this pattern can surprise people:

1import tensorflow as tf
2
3@tf.function
4def add_one(x):
5    tf.print("Inside traced function")
6    return x + 1
7
8value = add_one(tf.constant(4))
9print(value.numpy())

This is still normal TF2 behavior. You are not "back in TF1" globally; you are using a graph-compiled function inside an eager-first framework.

For debugging, you can temporarily force tf.function calls to run eagerly:

1import tensorflow as tf
2
3tf.config.run_functions_eagerly(True)
4
5@tf.function
6def add_one(x):
7    print("Python debugging output")
8    return x + 1
9
10print(add_one(tf.constant(4)).numpy())

That switch is helpful while debugging, but it is not something you normally leave on in performance-sensitive code.

A Simple Migration Mindset

When updating old tutorials, it helps to translate intent instead of mechanically renaming APIs.

Old intent:

• enable eager mode
• create tensors
• inspect values directly

New TF2 expression of that intent:

• do nothing special
• create tensors
• inspect values directly

The only time you should reach for tf.compat.v1.enable_eager_execution() is when you must preserve legacy structure during a gradual migration.

Common Pitfalls

The most common mistake is trying random replacements such as tf.enable_eager_execution, tf.keras.enable_eager_execution, or imports from unrelated modules. In modern TensorFlow, the simplest fix is usually deletion.

Another mistake is calling tf.compat.v1.enable_eager_execution() after other TensorFlow graph-related work has already started. That can fail because the runtime mode has to be chosen early.

Developers also misread tf.function behavior as proof that eager execution is disabled. It is not. tf.function deliberately traces graph code inside a TensorFlow 2 program.

Finally, avoid mixing large amounts of tf.compat.v1 code with new TF2 patterns unless you are intentionally migrating legacy code. The compatibility layer is useful, but it increases cognitive overhead.

Summary

• 'tf.enable_eager_execution() is an old TensorFlow 1 style API and is not the normal TF2 interface.'
• In TensorFlow 2, eager execution is already enabled by default.
• For new code, remove the call instead of replacing it.
• For legacy migration, use tf.compat.v1.enable_eager_execution() only at program startup.
• If behavior looks graph-like inside tf.function, that is expected and separate from the original attribute error.