Introduction

TensorFlow 1.9 and Python 3.7 arrived at nearly the same point in time, which is why this compatibility question comes up so often. The short answer is no: TensorFlow 1.9 did not publish official Python 3.7 support, so the stable path is to use Python 3.6 or upgrade TensorFlow.

The Short Answer

TensorFlow 1.9 was released in July 2018, right as Python 3.7 was becoming available. The published package metadata for TensorFlow 1.9 listed Python 2.7, 3.4, 3.5, and 3.6, but not 3.7. That means you should treat Python 3.7 as unsupported for that release, even if someone claims they made it work on a specific machine.

Unsupported does not always mean impossible. It means there were no official wheels, no tested support target, and no guarantee that installation, native extensions, or runtime behavior would be reliable.

What Failure Usually Looks Like

Most users run into the problem during installation rather than during model training. Typical symptoms include:

• 'pip reporting that no matching distribution could be found'
• build failures when trying to compile from source
• ABI or dependency mismatches in extension modules

A typical failed installation attempt looks like this:

1python3.7 -m venv tf19
2source tf19/bin/activate
3pip install --upgrade pip
4pip install tensorflow==1.9.0

On an unsupported interpreter, pip may refuse to install a wheel because none was published for that Python version.

The Safe Option: Use Python 3.6

If you specifically need TensorFlow 1.9, the safest approach is to create an isolated Python 3.6 environment. That matches the version range the package actually targeted.

1python3.6 -m venv tf19-py36
2source tf19-py36/bin/activate
3pip install --upgrade pip setuptools wheel
4pip install tensorflow==1.9.0
5python -c "import tensorflow as tf; print(tf.__version__)"

This keeps your legacy project working without forcing unsupported combinations into the same interpreter.

If your system no longer ships Python 3.6, tools like pyenv, Conda, or container images are usually easier than trying to retrofit old dependencies into a modern global Python installation.

When an Upgrade Is Better

If you are not locked to TensorFlow 1.9 by a legacy codebase, upgrading TensorFlow is usually the more rational fix. Version compatibility matters because TensorFlow is not a pure Python library. Large parts of the package are compiled native code, so wheel availability and ABI support matter as much as Python syntax compatibility.

Here is the general decision rule:

• keep TensorFlow 1.9 only if the project truly depends on 1.x behavior
• otherwise upgrade TensorFlow and run the project on a supported Python version

For example, if your code only uses high-level Keras-style APIs, the migration cost may be far lower than maintaining an old interpreter forever.

What About Building from Source

In theory, you can try to build TensorFlow 1.9 from source against Python 3.7. In practice, that is usually more work than the project is worth unless you have a strong reason to preserve that exact stack. Source builds introduce compiler, Bazel, and dependency constraints on top of the original Python mismatch.

Even if you succeed, you still own the maintenance burden. That means future reproductions, CI setup, and teammate onboarding all become harder.

A minimal example of the kind of validation you would need after any custom build is straightforward:

1import tensorflow as tf
2
3a = tf.constant(2)
4b = tf.constant(3)
5
6with tf.Session() as sess:
7    print(sess.run(a + b))

If a custom build cannot even pass a tiny smoke test like this, it is not a trustworthy foundation for real model training.

Choosing Between Compatibility and Migration

A useful way to think about the problem is to separate interpreter compatibility from application compatibility. Sometimes the application only needs small TensorFlow 1.x compatibility shims. In those cases, upgrading the library is simpler than freezing the entire runtime around one historical release.

If the project is large and migration is not possible right now, pin the full environment explicitly:

• Python version
• TensorFlow version
• OS image
• CUDA and cuDNN versions, if relevant

That approach is much more repeatable than trying to install old TensorFlow releases into whichever Python version happens to be installed on a workstation today.

Common Pitfalls

Assuming that a package will work on a newer Python version just because the release dates are close is a common mistake. Native wheels must be built and tested for that interpreter.

Confusing "may compile from source" with "officially supported" leads teams into brittle environments that are difficult to reproduce.

Upgrading only Python while leaving the rest of a legacy TensorFlow 1.x stack untouched often produces harder failures than keeping the original environment frozen.

Summary

• TensorFlow 1.9 did not provide official Python 3.7 support.
• The supported Python versions published for that release stopped at Python 3.6.
• If you need TensorFlow 1.9, use an isolated Python 3.6 environment.
• If you do not need 1.9 specifically, upgrading TensorFlow is usually the better long-term choice.
• Building from source is possible in theory, but it is a maintenance-heavy fallback rather than the default answer.