Python
TensorFlow
AttributeError
Machine Learning
Debugging

AttributeError module 'tensorflow' has no attribute 'get_default_graph'

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

AttributeError: module 'tensorflow' has no attribute 'get_default_graph' almost always means TensorFlow 1.x code is being executed on TensorFlow 2.x. The API moved away from the old global graph model, so legacy session-based code now needs either compatibility shims or a real migration to eager execution.

Why the Function Disappeared

In TensorFlow 1.x, many programs built a static computation graph first and executed it later inside a session. tf.get_default_graph() was part of that model because operations were attached to a global default graph unless you managed graphs manually.

TensorFlow 2.x changed the default execution style:

  • Eager execution runs operations immediately
  • 'tf.Session() is no longer the normal control flow'
  • Many graph-mode functions moved into tf.compat.v1

So code like this fails in TensorFlow 2.x:

python
import tensorflow as tf

graph = tf.get_default_graph()

The module exists, but the top-level symbol does not.

Quick Compatibility Fix

If you are maintaining legacy code and need the smallest possible change, use the compatibility namespace:

python
1import tensorflow as tf
2
3graph = tf.compat.v1.get_default_graph()
4print(graph)

If the whole codebase depends on sessions, placeholders, and graph collections, you can go one step further:

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

That keeps old code running, but it is a compatibility bridge, not a modern TensorFlow style.

Preferred Fix: Rewrite for TensorFlow 2.x

For new work, or for code you actively maintain, it is better to remove the dependency on the default graph entirely. In TensorFlow 2.x, operations execute eagerly and models are usually written with tf.keras, tf.function, and GradientTape.

Here is the TensorFlow 2.x style of the same idea:

python
1import tensorflow as tf
2
3x = tf.constant(3.0)
4y = x * 2.0
5
6print(y.numpy())

If you want graph compilation for performance, wrap the function with tf.function:

python
1import tensorflow as tf
2
3@tf.function
4def double_value(x):
5    return x * 2.0
6
7result = double_value(tf.constant(3.0))
8print(result.numpy())

This still creates an optimized graph internally, but you no longer manage a global default graph by hand.

Where This Error Shows Up in Real Projects

The failure often appears in one of three situations:

  • Old tutorials copied into a TensorFlow 2.x environment
  • A third-party library written for TensorFlow 1.x
  • Mixed imports from tensorflow, tensorflow.compat.v1, and standalone keras

The third case is especially messy. If one part of the program assumes eager execution and another part assumes session-managed graphs, the code may fail in unpredictable ways beyond this single error.

Migrating Larger Codebases

If you have a substantial TensorFlow 1.x project, start with the official upgrade tool:

bash
tf_upgrade_v2 --intree old_project --outtree migrated_project

That tool does not complete the migration for you, but it catches many renamed APIs and inserts compatibility references where appropriate. After that, refactor high-value code paths away from sessions and placeholders first.

A good practical order is:

  1. Replace top-level removed APIs with tf.compat.v1.
  2. Get the test suite passing.
  3. Migrate model code to tf.keras.
  4. Replace session-based execution with eager code and tf.function.

Common Pitfalls

One common mistake is mixing tensorflow.compat.v1 and native TensorFlow 2.x patterns in the same module without a clear boundary. That makes it harder to reason about execution mode and often creates secondary bugs.

Another issue is assuming this error always comes from your own code. Older third-party packages may still call tf.get_default_graph() internally. If your code looks clean, inspect pinned dependencies.

Developers also sometimes disable v2 behavior everywhere just to silence one failing import. That can freeze the project in an outdated execution model and make future migration harder.

Finally, do not confuse tf.function with the old global graph API. Both involve graphs, but tf.function is scoped and explicit, not centered around tf.get_default_graph().

Summary

  • The error usually means TensorFlow 1.x graph-mode code is running on TensorFlow 2.x.
  • The short-term fix is tf.compat.v1.get_default_graph().
  • The long-term fix is to migrate away from sessions and the global graph model.
  • Use tf.function when you want graph execution in TensorFlow 2.x.
  • Check third-party dependencies if your own code no longer references get_default_graph().

Course illustration
Course illustration

All Rights Reserved.