Introduction

from keras.backend.tensorflow_backend import set_session is a legacy Keras and TensorFlow 1 pattern used to control the TensorFlow session that Keras should use. You will still see it in older code for limiting GPU memory growth or sharing a custom-configured session.

In modern TensorFlow 2 with tf.keras, that import path is obsolete. Session management is no longer the normal user-facing abstraction, so the correct migration path is to use TensorFlow 2 configuration APIs instead of trying to keep set_session alive.

What the Old Import Was For

In TensorFlow 1, Keras often ran on top of a manually created TensorFlow session. Developers used set_session to tell Keras which session to use.

1import tensorflow as tf
2from keras.backend.tensorflow_backend import set_session
3
4config = tf.ConfigProto()
5config.gpu_options.allow_growth = True
6sess = tf.Session(config=config)
7set_session(sess)

This was common in older GPU setups where grabbing all GPU memory up front caused problems.

Why It Breaks in Modern Code

There are two related changes:

• standalone Keras and tf.keras converged around TensorFlow 2
• TensorFlow 2 uses eager execution by default instead of session-centric graph execution

Because of that, the old backend import may be missing entirely, and even if you find a compatibility path, it is usually the wrong abstraction for current code.

Modern TensorFlow 2 Equivalent

If the old code used set_session for GPU memory behavior, use TensorFlow 2 device configuration instead.

1import tensorflow as tf
2
3gpus = tf.config.list_physical_devices('GPU')
4for gpu in gpus:
5    tf.config.experimental.set_memory_growth(gpu, True)
6
7print(gpus)

This is the modern replacement for the common “do not allocate all GPU memory at startup” use case.

Migrate the Rest of the Stack Too

If a project still imports set_session, it often also depends on other TensorFlow 1 era patterns such as explicit graphs, placeholders, or old optimizer APIs. Fixing only the import may leave the rest of the code half-migrated.

A better migration sequence is:

1. move imports to tensorflow.keras or tf.keras
2. replace session configuration with tf.config APIs where needed
3. remove graph and session assumptions from training code

That produces code that matches the current TensorFlow model instead of using compatibility shims forever.

When Compatibility Mode Is Still Used

If you are temporarily stuck on TensorFlow 1 style code, tf.compat.v1 may keep the project running during a migration window. That can be useful for maintenance, but it should be treated as a bridge, not as the final design. New projects should not be built around sessions unless there is a very specific legacy constraint.

That is especially true for examples found online. A code sample that only fixes the import line but keeps the rest of the TF1 execution model usually postpones the migration problem rather than solving it.

Common Pitfalls

• Searching for a modern import path for set_session instead of migrating away from session management.
• Mixing standalone old Keras imports with modern tf.keras imports in the same project.
• Assuming the only purpose of set_session was syntax rather than TensorFlow 1 execution control.
• Migrating the import but leaving the rest of the code dependent on sessions and graphs.
• Using old GPU-memory examples without checking whether TensorFlow 2 already exposes a direct config API.

Summary

• 'set_session is a legacy Keras and TensorFlow 1 pattern.'
• It was used to tell Keras which TensorFlow session to use.
• In TensorFlow 2, the usual replacement is not a new set_session import.
• For GPU memory behavior, use tf.config APIs such as memory growth.
• If code still depends on set_session, it is usually time to migrate the surrounding TensorFlow 1 patterns too.