Introduction

In TensorFlow 2, you usually do not organize model code the way you did in TensorFlow 1. The old tf.variable_scope pattern was built around graph construction and variable reuse rules, while TF2 pushes you toward tf.keras layers, models, and ordinary Python composition.

That does not mean scoping disappeared completely. tf.name_scope still exists for naming operations, but the main way to “group” a model in TF2 is to create named layers and named submodels rather than relying on TF1-style variable-scope machinery.

Group Logic with Named Keras Layers and Models

The most natural TF2 answer is to encapsulate related operations inside custom Layer or Model classes. Give them meaningful names and TensorFlow will use those names in variable paths, summaries, and graph visualizations.

1import tensorflow as tf
2
3
4class EncoderBlock(tf.keras.layers.Layer):
5    def __init__(self, units, name=None):
6        super().__init__(name=name)
7        self.dense1 = tf.keras.layers.Dense(units, activation="relu", name="dense1")
8        self.dense2 = tf.keras.layers.Dense(units, activation="relu", name="dense2")
9
10    def call(self, inputs):
11        x = self.dense1(inputs)
12        return self.dense2(x)
13
14
15inputs = tf.keras.Input(shape=(16,), name="features")
16x = EncoderBlock(32, name="encoder_block")(inputs)
17outputs = tf.keras.layers.Dense(1, name="prediction")(x)
18
19model = tf.keras.Model(inputs, outputs, name="demo_model")
20model.summary()

This approach gives you logical grouping without manually managing TF1-style scopes. In TensorBoard and variable names, you will typically see names derived from the layer and model hierarchy.

Use tf.name_scope for Operation Naming

tf.name_scope is still useful in TF2 when you want clearer names for low-level ops, especially inside custom layers or custom training steps.

1import tensorflow as tf
2
3
4class ResidualAdd(tf.keras.layers.Layer):
5    def call(self, x, y):
6        with tf.name_scope("residual_ops"):
7            summed = tf.add(x, y, name="sum")
8            return tf.nn.relu(summed, name="relu")
9
10
11layer = ResidualAdd()
12result = layer(tf.constant([1.0, -2.0]), tf.constant([3.0, 1.0]))
13print(result.numpy())

This does not replace Keras structure. It complements it by making the underlying operations easier to read in traces and graph tools.

Why tf.variable_scope Is Usually Not the TF2 Answer

In new TF2 code, variable ownership and reuse are handled by object-oriented composition. If you want shared variables, you reuse the same Layer instance. You do not typically call tf.compat.v1.get_variable and manage reuse flags yourself.

1import tensorflow as tf
2
3shared_dense = tf.keras.layers.Dense(8, activation="relu", name="shared_dense")
4
5inputs = tf.keras.Input(shape=(4,))
6x1 = shared_dense(inputs)
7x2 = shared_dense(inputs)
8outputs = tf.keras.layers.Concatenate()([x1, x2])
9
10model = tf.keras.Model(inputs, outputs)

Here, variable sharing happens because the same layer object is called twice. That is the TF2-native replacement for many older variable_scope(reuse=True) use cases.

When tf.compat.v1.variable_scope Still Appears

tf.compat.v1.variable_scope still exists, but it is a legacy compatibility API. It is mainly relevant when migrating TF1 models, preserving checkpoint naming, or maintaining older code paths that still depend on get_variable semantics.

If you are writing a fresh TF2 Keras model, reaching for tf.compat.v1.variable_scope is usually a sign that you are carrying TF1 habits into a codebase that no longer needs them.

A Good TF2 Grouping Strategy

For new projects, a practical grouping strategy looks like this:

• use custom Layer subclasses for reusable blocks
• use meaningful name= values on layers and models
• use tf.name_scope only when you want better op names inside a block
• compose blocks through tf.keras.Model instead of manually managing variable namespaces

That gives you cleaner code, easier checkpointing, and a structure that matches how modern TensorFlow expects models to be built.

Common Pitfalls

The biggest mistake is trying to port TF1 graph-organization patterns line by line into TF2. Doing that often produces code that is harder to read than a straightforward Keras model.

Another issue is confusing operation naming with variable reuse. tf.name_scope can prefix operation names, but it is not the TF1 replacement for variable_scope reuse behavior.

People also create multiple identical layer instances when they actually want shared weights. In TF2, weight sharing comes from reusing the same layer object, not from naming two separate layers the same thing.

Finally, if you are migrating legacy checkpoints, remember that compatibility requirements can justify using tf.compat.v1 APIs temporarily. That is a migration concern, not the recommended design for new code.

Summary

• In TF2, group model logic mainly through named tf.keras layers and models.
• 'tf.name_scope still exists and is useful for clearer operation names.'
• 'tf.compat.v1.variable_scope is a legacy compatibility tool, not the normal TF2 solution.'
• Reuse the same layer instance when you want shared weights.
• Prefer object-oriented model composition over TF1-style manual graph scoping.