Introduction

Running Python 3.6 inside Google Colab is difficult because Colab controls the hosted runtime and does not exist to preserve old interpreter versions indefinitely. For legacy code, the real question is not "how do I downgrade Colab" but "how do I run Python 3.6-compatible code while still using a notebook workflow." In practice, the most reliable options are a local runtime, a container, or modernizing the code so it no longer depends on 3.6.

Why Hosted Colab Is the Wrong Place for a Hard Python 3.6 Requirement

Colab is a managed environment. You get convenience, but you do not get full control of the base interpreter version. Even if you manage to install some Python 3.6 binaries into a notebook session, the notebook kernel and the surrounding environment are still built around the hosted runtime that Colab chose.

That means:

• package compatibility becomes fragile
• notebook restarts can undo your work
• system libraries may not match the interpreter you are trying to force in

If a project truly requires Python 3.6, treat that as an environment management problem, not a notebook cell trick.

First, Check the Active Version

Always confirm what interpreter the notebook is actually using.

1import sys
2
3print(sys.version)
4print(sys.executable)

This tells you whether you are in the default hosted Colab runtime or a custom/local runtime setup.

Recommended Option 1: Use a Local Jupyter Runtime with Python 3.6

The most practical way to keep the Colab notebook interface while controlling Python is to run Jupyter locally and connect Colab to it.

Create a Python 3.6 virtual environment on your own machine:

1python3.6 -m venv colab36
2source colab36/bin/activate
3python -m pip install --upgrade pip
4python -m pip install notebook jupyter_http_over_ws
5jupyter serverextension enable --py jupyter_http_over_ws

Start the notebook server:

1jupyter notebook \
2  --NotebookApp.allow_origin='https://colab.research.google.com' \
3  --port=8888 \
4  --NotebookApp.port_retries=0

Then in Colab, connect to the local runtime instead of using the hosted one. This gives you Python 3.6 under your control while keeping the notebook UI.

Recommended Option 2: Use Docker for Reproducibility

If your local environment is messy or shared, a container is cleaner.

Example Dockerfile:

1FROM python:3.6-slim
2
3RUN pip install --no-cache-dir notebook jupyter_http_over_ws \
4    && jupyter serverextension enable --py jupyter_http_over_ws
5
6WORKDIR /workspace
7EXPOSE 8888
8
9CMD ["jupyter", "notebook", "--ip=0.0.0.0", "--port=8888", "--no-browser", "--allow-root", "--NotebookApp.allow_origin=https://colab.research.google.com"]

Build and run:

docker build -t colab-py36 .
docker run --rm -p 8888:8888 -v "$PWD":/workspace colab-py36

Now connect Colab to that local runtime. This keeps dependencies reproducible and isolated from your host system.

Recommended Option 3: Stop Requiring Python 3.6

For many projects, the better fix is to remove the dependency on 3.6 rather than preserve it. Python 3.6 is old enough that package support and security posture become liabilities.

A quick compatibility audit can help:

1import sys
2
3required = (3, 6)
4print("Running:", sys.version_info[:3])
5print("Expected minimum:", required)
6print("Compatible:", sys.version_info[:2] >= required)

Then inspect what really forces the old version:

• syntax assumptions
• pinned packages
• C-extension wheels that never got rebuilt
• old TensorFlow or notebook dependencies

Often the real blocker is one package pin, not the project itself.

What Not to Do in Hosted Colab

Avoid trying to replace the system interpreter in-place inside the hosted runtime. Even when commands seem to work temporarily, the environment is not designed for that.

Typical anti-pattern:

apt-get install python3.6
update-alternatives --set python /usr/bin/python3.6

This may appear to change python in a shell cell, but it does not reliably change the notebook kernel process or the rest of the Colab-managed stack.

If the notebook kernel itself is not running under 3.6, then your environment is not really a Python 3.6 notebook.

A Small Sanity Check for the Connected Runtime

When you connect Colab to a local or Docker-based runtime, verify that package installation and execution happen in the expected interpreter.

1import sys
2import subprocess
3
4print(sys.version)
5print(sys.executable)
6subprocess.run([sys.executable, "-m", "pip", "--version"], check=True)

This catches the common case where the shell and the notebook are using different Python environments.

Common Pitfalls

One common mistake is assuming that if python --version prints 3.6 in a shell cell, the notebook kernel is also 3.6. That is not necessarily true.

Another mistake is forcing old package versions into a modern hosted runtime and then debugging crashes caused by binary incompatibility.

Developers also underestimate maintenance cost. Keeping an obsolete interpreter alive in a managed notebook platform is usually more work than updating the project.

Finally, teams sometimes forget to document the local runtime setup. If reproducibility matters, capture the exact Python version and dependency install steps in code, not in tribal memory.

Summary

• Hosted Colab is not a reliable place to force Python 3.6.
• The practical solution is a local runtime or Docker-based Jupyter server connected to Colab.
• Verify the actual notebook interpreter with sys.version and sys.executable.
• Avoid in-place interpreter replacement tricks in the hosted runtime.
• If possible, remove the Python 3.6 requirement instead of preserving it.