Job python-runtime-3-9-or-3-10-to-3-13 · revised 11 October 2026
Move one Python 3.9 or 3.10 app to Python 3.13 with removed modules and wheels sorted
Run one Python 3.9 or 3.10 application on Python 3.13: dependencies installed from a clean environment, removed standard-library modules replaced, and the tests and named flows passing on a copy.
You might be seeing
- The Python developer guide lists your version as end of life
- A dependency upgrade fails because it no longer supports your Python version
- A build tries to compile a package from source because no prebuilt wheel exists for your interpreter
No passwords, keys, card details or admin invites needed to start.
What usually happened
The app runs on a Python release that no longer gets fixes. Moving from 3.9 or 3.10 to 3.13 crosses two sets of removals: Python 3.12 removed distutils, imp, asyncore and asynchat and stopped pre-installing setuptools in new virtual environments, and Python 3.13 removed 19 long-deprecated standard-library modules such as cgi, crypt, pipes and telnetlib. Compiled dependencies are published as wheels tied to specific interpreter versions, so a package that installed quietly before may have to build from source or be upgraded. A new interpreter that imports cleanly can still change behaviour in code that the tests never reach.
Who it’s for: A founder or engineering lead whose Python service, script collection or web app still runs on a release the Python project has stopped supporting.
Usually starts when: The Python version your app uses appears as end of life on the Python developer guide, a host or base image drops it, or a dependency you need has stopped publishing builds for it.
The result: The app installs in a clean environment on Python 3.13, none of its own code imports a removed standard-library module, the test suite passes as it did before, and the Python version is set consistently in the container, CI and host configuration, with a release plan and a way back for your site holder.
Check whether this job fits
Five short questions. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Read the interpreter version
Ask whoever works on the app to run this inside the environment the app uses.
python3 --versionLook for: The version number. Send the one from production if it differs from a developer machine.
List installed packages
Run this in the environment the app runs in and send the output; it holds package names and versions only.
python3 -m pip list --format=freezeLook for: A list of name==version lines. Send the list, nothing else.
What you get
- The changed code, requirements or lockfile and build configuration as a pull request
- A list of every removed-module use found and its replacement, and every dependency upgrade or replacement with the reason
- Test and install logs from the old and new interpreter
- A release plan with the order of changes and the steps to go back
Included
- One Python application or service with a pinned requirements file or lockfile and a runnable test command
- A clean install on Python 3.13, with each dependency upgraded to a release that supports it, or replaced with your agreement
- Finding and replacing every use of the standard-library modules removed in Python 3.12 and 3.13 in your own code, and checking the dependencies that import them
- Where the project builds packages, replacing uses of distutils with the build tooling the project already declares, and installing setuptools explicitly where code still needs it
- Setting the Python version in the container base image, CI configuration, project metadata and host settings so they agree, and a staging run of up to five named business flows
Not included
- Python 2 code, which needs a different assessment
- Major framework upgrades such as a new Django or Flask major, which are separate jobs
- A Python 3.14 target or other versions, which have their own changes to check
- Rewrites for performance, type hints or asynchronous code
- Production deployment, which stays with your site holder
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
In a clean environment on Python 3.13, installing from the pinned requirements finishes without error and the dependency consistency check reports no broken requirements
Evidence: The install log and the output of the consistency check
python3.13 -m pip checkThe test command finishes with the same tests passing as the recorded baseline on the old interpreter, or each difference is explained in writing and accepted by you
Evidence: Test output from the baseline and the final state
A search of the app's own code finds no import of distutils, imp, asyncore or asynchat or of any module on the Python 3.13 removal list, and importing every module of the app on 3.13 raises no import error
Evidence: The search result and the import-all log
The Python version in the container base image, CI configuration, project metadata and host settings names the same 3.13 line everywhere it is set
Evidence: A table of each place with old and new value, checked by the reviewer
Each of up to five named flows completes on staging with no new error in the application log
Evidence: Screenshots or redacted records and the log excerpt for the test window
Sign-off. You review the logs, the dependency changes and the list of replaced modules before your site holder changes the runtime in production. Passing tests on staging do not prove production traffic patterns.
If it fails. If the agreed acceptance checks do not pass, you do not pay and you keep our findings and the way-back steps.
When it fits, and when we stop
It fits when
- The app runs on Python 3.9 or 3.10 today and its dependencies are pinned or locked
- The test suite or a documented set of checks can run on a copy without production data or secrets
- Every dependency has a release that supports Python 3.13, or you accept a named replacement
- A person on your side can review the change and an authorised site holder can change the runtime in production
We stop and tell you if
- A required dependency has no release that supports Python 3.13 and no maintained replacement
- A dependency must be compiled from source and needs a toolchain or library we cannot provide on the copy
- The code is Python 2 or mixes Python 2 and 3
- The app can only be run with live secrets or production data
What could go wrong
Keep the previous container image or runtime setting and the previous requirements available. The way back is to restore them. If the app wrote serialised or cached values in a new format after release, the plan says how to check them before reverting.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A dependency installs from source on the copy but cannot be built in your build image | The install is run in the same kind of image your host uses, and the base image is part of the change. |
| A replacement for a removed module behaves differently in an edge case | Each replacement is covered by a test with the inputs the app really sees, taken from synthetic fixtures. |
| Code the tests never reach still imports a removed module | We search the code, not just the tested paths, and import every module in the app once on 3.13. |
A second reviewer checks every replaced standard-library module, every dependency change and each place the version is set, and re-runs the install from the handover notes alone.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Restore a copy in an isolated environment on the current Python version, run the tests and record the baseline and the installed package list
- Create a clean environment on Python 3.13 and install the dependencies, recording each package that needs upgrading, replacing or compiling
- Search the app's own code, and the dependencies that import them, for the standard-library modules removed in 3.12 and 3.13 and replace each use with a supported alternative
- Update the build files that used distutils, and install setuptools explicitly where code still needs it
- Align the interpreter version in the container, CI, project metadata and host settings, then run the tests and up to five named flows on staging
- Independent review of dependency changes and replaced modules, then hand over the pull request, the logs and the release and way-back steps
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a monthly service that keeps the interpreter and dependencies on supported versions.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Python 3.11 and 3.12 are still listed as receiving security fixes on the Python developer guide. Moving to one of them first is a smaller step, though it buys less time than 3.13. devguide.python.org
- The Python documentation lists what each release removed, with suggested replacements for the modules removed in 3.13. If your team can test the result against your real flows, starting from those notes is a sound option. docs.python.org
Questions
Why 3.13 and not the newest Python?
3.13 is listed as receiving security fixes until October 2029 and has had its removals documented for some time. A different target, including 3.14, is a different scope because its changes and tests differ.
My app is a Django project. Is this the right job?
Only if Django itself is already a version that supports Python 3.13. A framework major upgrade is a separate job.
What if a package no longer builds?
We say so with the evidence and either agree a replacement with you or stop. You do not pay for a result that does not pass its checks.
Send an enquiry
Send us
- The Python version in production and where the app is built, for example a container image or a host setting
- The names of the requirements files or lockfile, and how dependencies are installed
- Any dependencies you know need compiling, such as image, cryptography or database drivers
- The business flows that matter most
Later, once you agree
- A controlled copy of the source and pinned dependencies with secrets removed, through the agreed company-controlled secure handoff
- The Dockerfile, CI configuration and host settings values, with secrets removed
- Instructions to run the tests, plus synthetic fixtures if they need data
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the code, build pipeline, hosting and secrets. We work from an authorised copy with secrets removed, and your site holder changes the runtime in production under your accounts. We never ask for passwords or tokens in the first enquiry.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “python-runtime-3-9-or-3-10-to-3-13” as the subject.