Introduction

This warning appears when older TensorFlow or Keras code passes dtype to the VarianceScaling constructor instead of supplying the data type at call time or at the layer level. The fix is usually small: stop putting dtype inside the initializer constructor and let the layer or the initializer call decide the type.

What the Warning Means

Legacy initializer code often looked like this:

1import tensorflow as tf
2
3initializer = tf.keras.initializers.VarianceScaling(
4    scale=2.0,
5    mode="fan_in",
6    distribution="truncated_normal",
7    dtype=tf.float32,
8)

That constructor-level dtype is what triggers the deprecation warning. Newer TensorFlow guidance is to create the initializer without dtype and pass the type when the initializer is called, or simply let the layer manage its own dtype.

The Direct Fix

If you are calling the initializer yourself, move dtype to the call site:

1import tensorflow as tf
2
3initializer = tf.keras.initializers.VarianceScaling(
4    scale=2.0,
5    mode="fan_in",
6    distribution="truncated_normal",
7)
8
9weights = tf.Variable(initializer(shape=(128, 64), dtype=tf.float32))
10print(weights.dtype)

This matches the current API direction: configure the initializer's behavior in the constructor, then provide shape and dtype when generating actual values.

The Usual Layer-Level Fix

Most Keras code does not call the initializer directly. Instead, it passes the initializer into a layer such as Dense or Conv2D. In that case, remove dtype from the initializer and set the layer dtype if you need one explicitly.

1import tensorflow as tf
2
3layer = tf.keras.layers.Dense(
4    64,
5    dtype="float32",
6    kernel_initializer=tf.keras.initializers.VarianceScaling(
7        scale=2.0,
8        mode="fan_in",
9        distribution="truncated_normal",
10    ),
11)

This keeps dtype ownership in the layer, which is usually the cleanest design in Keras models.

Why the API Changed

The underlying idea is separation of concerns. The initializer describes how values should be sampled. The layer or initializer call decides what shape and dtype those values should actually have.

That split makes the API more consistent with other initializer patterns and reduces confusion when the same initializer object is reused in different contexts.

It also keeps mixed-precision and layer-level dtype policies in one place instead of scattering dtype choices across every initializer definition.

Where the Warning Usually Comes From

This warning often appears in older tutorials, copied snippets, or migration code that still follows TensorFlow 1 style habits. It can also show up indirectly through legacy wrappers or compat.v1 code.

If you are using an older compatibility API, the long-term fix may be bigger than one line. But for native tf.keras.initializers.VarianceScaling, removing constructor-level dtype is the immediate solution.

In practice, most codebases can fix the warning by updating only the initializer definition and leaving the surrounding model logic unchanged. That is why this warning is usually low-risk to fix.

Common Pitfalls

• Removing dtype from the constructor but forgetting to set dtype somewhere else can cause the layer to use its default type instead.
• The warning is about where dtype is passed, not about VarianceScaling itself being deprecated.
• If the warning comes from third-party or legacy framework code, your application code may not be the only place that needs updating.
• When using Keras layers, prefer setting dtype on the layer or model policy instead of on the initializer constructor.

Summary

• Do not pass dtype to VarianceScaling(...) in newer TensorFlow or Keras code.
• If you call the initializer directly, pass dtype when invoking it with shape.
• If you use the initializer in a layer, set dtype on the layer when needed.
• The warning is usually a small migration issue, not a signal that you should stop using VarianceScaling.