3.6 released 23 December 2016, latest 3.6.15.
Python 3.6 reached end of life on 23 December 2021.
What changed
Python 3.6 added formatted string literals, commonly called f-strings, for inline expression formatting; variable annotations for type-hint metadata; asynchronous generators and asynchronous comprehensions; underscores in numeric literals; and a secrets module for security-sensitive random values. It also added the datetime fold attribute to distinguish repeated local times during clock changes. CPython 3.6 preserved dictionary insertion order as an implementation behavior, although that behavior did not become a language-level guarantee until the following Python cycle. The release also expanded standard-library and typing support, including improvements around pathlib, enum, and asynchronous programming.
What staying costs
Python 3.6 has reached end of life, so it no longer receives upstream security fixes or routine bug fixes. Continuing to run it leaves known and newly discovered interpreter and standard-library vulnerabilities unpatched unless a downstream vendor supplies its own backports. Dependency risk increases over time because package maintainers commonly stop testing, publishing wheels, or releasing compatible versions for unsupported Python lines. This is especially consequential for services using native extensions, modern cryptography or TLS stacks, build tooling, and platform images, where installation failures or an inability to adopt security updates can become operational constraints. Staying also preserves older runtime behavior and tooling assumptions, making a later migration larger and less well tested.
What to do
Identify every production, build, automation, and developer environment that still invokes Python 3.6, including embedded interpreters, containers, CI jobs, serverless deployments, and scripts. Select a currently supported target Python version that is compatible with the operating systems, deployment platforms, and third-party packages you need. Create a representative test environment on that target, upgrade dependencies to versions that support it, and rebuild native extensions and wheels rather than reusing artifacts built for Python 3.6. Run unit, integration, packaging, and deployment tests under both versions during the transition, paying particular attention to dependency constraints, text and bytes handling, time-zone behavior, warnings, and any code relying on undocumented CPython details. Update CI and packaging metadata to test and declare the new minimum version, then deploy incrementally with monitoring and a rollback plan. Remove Python 3.6 from supported execution paths once workloads have moved.
We can tell you what moving off Python 3.6 involves.
What it takes to move off Python 3.6 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.
Not sure yet? Get my plan
