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:
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:
If the whole codebase depends on sessions, placeholders, and graph collections, you can go one step further:
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:
If you want graph compilation for performance, wrap the function with tf.function:
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 standalonekeras
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:
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:
- Replace top-level removed APIs with
tf.compat.v1. - Get the test suite passing.
- Migrate model code to
tf.keras. - 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.functionwhen you want graph execution in TensorFlow 2.x. - Check third-party dependencies if your own code no longer references
get_default_graph().

