Introduction

If TensorFlow 1.15 shows deprecation warnings when you import Keras symbols from internal paths such as tensorflow.python.keras, the warning is doing its job. Those internal modules were never meant to be the stable public API. In TensorFlow 1.15, the supported surface is tf.keras, and the long-term migration path is toward TensorFlow 2 style usage.

Why the Warning Appears

TensorFlow has public APIs and internal implementation modules. The tensorflow.python.* package tree is internal. It may exist in your environment, but it is not the contract TensorFlow expects application code to depend on.

That means code like this is fragile:

from tensorflow.python.keras.layers import Dense

The supported import is:

import tensorflow as tf

layer = tf.keras.layers.Dense(32)

Using the public namespace avoids warnings and keeps your code aligned with the documented API.

What to Change in TensorFlow 1.15

The first cleanup step is to replace internal imports with tf.keras equivalents wherever possible.

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Dense(64, activation="relu", input_shape=(10,)),
5    tf.keras.layers.Dense(1)
6])
7
8model.compile(optimizer="adam", loss="mse")

This is still valid TensorFlow 1.15 code, but it uses the supported Keras surface instead of internal implementation paths.

If your code also relies on graph-mode behavior, sessions, or placeholders, keep those TensorFlow 1.x patterns where necessary, but separate that concern from the Keras import issue. The warning is usually about the import path, not about whether you are in eager mode.

Why Internal Imports Are Tempting

Developers often reach into tensorflow.python.keras because examples, autocomplete, or stack traces reveal internal symbols. Sometimes an internal module appears to expose a class that is harder to find from the public API.

That is still not a good reason to depend on it. Internal TensorFlow paths are implementation details. Even when they work in one version, they are more likely to move, warn, or break in another environment.

In other words, "importable" does not mean "supported."

Separate Short-Term Cleanup From Full Migration

If you are maintaining a TensorFlow 1.15 codebase, there are two levels of change.

Short-term cleanup:

• replace tensorflow.python.keras imports with tf.keras
• stop depending on undocumented internal modules
• keep the rest of the TensorFlow 1.x execution model stable while you reduce warnings

Long-term migration:

• move toward TensorFlow 2 APIs
• remove session-oriented patterns where possible
• adopt modern saving and training workflows

These are different tasks. You do not need a full framework migration just to stop one class of deprecation warnings.

A Practical Before-and-After Example

Before:

1from tensorflow.python.keras.models import Sequential
2from tensorflow.python.keras.layers import Dense
3
4model = Sequential()
5model.add(Dense(16, input_dim=4, activation="relu"))
6model.add(Dense(1))

After:

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Dense(16, input_shape=(4,), activation="relu"),
5    tf.keras.layers.Dense(1)
6])

The functionality is the same, but the second version uses the public contract that TensorFlow intended application code to use.

Common Pitfalls

The most common mistake is assuming that because an internal import works today, it is safe to keep using it.

Another mistake is mixing public tf.keras imports and internal tensorflow.python.keras imports in the same project. That makes later cleanup harder and increases the chance of confusing warnings.

A third issue is treating every deprecation warning as a demand for a full framework rewrite. Often the immediate fix is just to stop importing internals.

Finally, do not silence warnings without understanding them. In a legacy TensorFlow codebase, the warnings often point directly to the highest-risk maintenance hotspots.

Summary

• 'tensorflow.python.keras is an internal implementation path, not the supported public API.'
• In TensorFlow 1.15, application code should prefer tf.keras imports.
• Replacing internal imports is usually the first fix for these deprecation warnings.
• Import cleanup is a smaller task than a full migration to TensorFlow 2.
• Internal modules may be visible and usable, but they are not a stable contract.
• Treat deprecation warnings as maintenance guidance, not noise to suppress blindly.