Python 3.13 Broke Your Code? Here's How to Fix It

Traceback (most recent call last):
  File "/app/server.py", line 3, in <module>
    import cgi
ModuleNotFoundError: No module named 'cgi'

Yeah, they deleted it. Along with 18 other modules. Because fuck backwards compatibility, right? PEP 594 nuked: aifc, audioop, cgi, cgitb, chunk, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, and xdrlib.

Copy these, they work:

• cgi.parse_qs() → urllib.parse.parse_qs()
• imghdr.what() → pip install pillow then PIL.Image.open()
• mailcap.findmatch() → mimetypes.guess_type()

ERROR: Could not find a version that satisfies the requirement some-package==1.2.3
ERROR: No matching distribution found for some-package==1.2.3

The maintainer hasn't built wheels for Python 3.13 yet. Or they just don't give a shit about supporting the latest Python version. Here's what actually works when you're stuck:

• Check the conda-forge migration tracker - they usually get wheels before PyPI
• Stick with Python 3.11 or 3.12 until this resolves (6-12 months is normal)
• Try pip install --pre some-package for release candidates
• If you're feeling masochistic, compile from source with pip install --no-binary :all:

error: Microsoft Visual C++ 14.0 is required. Get it with "Build Tools for Visual Studio"
building 'some_extension' extension
gcc: error: Python.h: No such file or directory

Feels like 2010 all over again - you're compiling C extensions because nobody bothered making wheels for Python 3.13 yet.

What actually works:

• Windows: Install "Microsoft C++ Build Tools" (not the full Visual Studio)
• Ubuntu: sudo apt install build-essential python3-dev
• macOS: xcode-select --install
• Better option: Use conda/mamba instead - they have binaries when PyPI doesn't
• Nuclear option: Downgrade to Python 3.12 where everything has wheels

Fuck no. Not unless you enjoy 3am debugging sessions.

It's been almost a year since release and Python 3.13.7 finally works, but your dependencies might still be fucked. I learned this the hard way when our Django app died because we used cgi.parse_qs in some forgotten legacy module.

Reality check timeline:

• Wait 6+ months minimum for ecosystem stability
• Check every single package in requirements.txt has 3.13 wheels
• Test thoroughly in staging - compatibility hell is real
• Python 3.12 gets security updates until 2028, so there's no rush

I made this mistake in June 2024 trying to be an early adopter. Spent a weekend migrating our API, only to find that psycopg2 wheels didn't exist yet and compilation kept shitting the bed with cryptic GCC errors. Rolled back and waited until December. Learned the hard way that being first to upgrade just means first to break.

>>> print("hello")  # This line is now syntax highlighted
hello
>>> # Multi-line editing works but feels wrong

Python 3.13's new REPL has colors and multi-line editing. If you hate it:

• export PYTHON_BASIC_REPL=1 - back to the old boring REPL
• export NO_COLOR=1 - disable colors only
• Add these to your .bashrc or .zshrc to make it permanent

AttributeError: module 'os' has no attribute 'tempnam'AttributeError: module 'audioop' has no attribute 'ratecv'Congrats, you found code that relied on deprecated shit nobody should use anymore.

The error message tells you absolutely nothing useful as usual.Debug this garbage:

• Run with python -Wd to see warnings you've been ignoring for years
• Search the Python 3.13 changelog for the missing attribute
• Check if it moved to another module (it probably did)
• For os.tempnam() specifically: use tempfile.mktemp() instead

```Step 4/8 :

RUN pip install -r requirements.txt ---> Running in 9c8f5b4d2e3aERROR: Could not find a version that satisfies the requirement some-package```Alpine Linux strikes again.

Or you're trying to compile C extensions in a minimal container without build tools.Copy-paste fixes:```dockerfile# For slim images that actually work:

FROM python:
3.13-slimRUN apt-get update && apt-get install -y build-essential python3-dev```

• Skip Alpine unless you hate yourself
• it breaks everything due to musl vs glibc bullshit
• Use python: 3.13-bullseye for maximum compatibility with C extensions
• Try python: 3.13-slim-bullseye as a middle ground
• smaller but still works
• Multi-stage builds if you must minimize image size
• compile in fat image, copy to slim image

 Python.h: No such file or directoryfatal error C1083:

 Cannot open include file: 'Python.h'src/extension.c(23): error C2039: 'PyObject': unknown type name```Python 3.13 changed some C API shit and your extension is from 2019.

 Time to update or abandon ship.**Try this shit:**
- Update Cython to 3.0.5+ 
- they fixed the 3.13 compatibility 
- Check if the package has a newer release (probably not)
- Use the [stable ABI](https://docs.python.org/3/c-api/stable.html) if you're maintaining this yourself
- Consider [scikit-build-core](https://scikit-build-core.readthedocs.io/) for less painful C++ builds

The JIT is disabled by default and free-threading adds overhead even when you don't use it.

Plus they changed some internal optimizations.Debug your performance regression:

• Try python -X jit
• the JIT might help CPU-heavy code (but adds startup overhead)
• Profile with cProfile to find actual bottlenecks: python -m cProfile -s cumtime your_script.py
• Compare identical workloads: time python3.12 script.py vs time python3.13 script.py
• Could be your packages
• some had to rewrite optimizations for 3.13 compatibility
• Use py-spy for live profiling if the regression happens in production
• Performance varies a lot between workloads
• I/O bound code sees no difference

ResolutionImpossible: Could not find a version that satisfies the requirement package-a>=2.0; package-b<3.0 requires package-a<2.0```Welcome to dependency hell.

 Some packages support 3.13, their dependencies don't, and pip gives up.**Fixes that actually work:**
- `pip-tools` 
- generates locked requirements that actually resolve
- Switch to Poetry or PDM 
- better dependency resolution than pip
- Use separate virtual environments for testing before migration
- Consider conda/mamba 
- they solve this better than pipThis shit happened to me with a Flask project where `requests-oauthlib` needed an older version of `requests` that conflicted with everything else. Took an hour with Poetry to sort out what pip couldn't figure out in 3 attempts. The dependency resolver in pip is garbage.