Introduction

Python writes .pyc files as bytecode caches so imported modules can load faster on later runs. If you want to avoid them, the best method depends on your actual goal: disabling cache writes for one command, disabling them for an environment, or keeping cache files out of your source tree without turning caching off completely.

Understand What .pyc Files Are Doing

When Python imports a module, it compiles the source code into bytecode. That bytecode is usually written under __pycache__ so the next import can skip some compilation work.

In other words, .pyc files are not errors or leftovers from a broken setup. They are normal cache files. Many projects do not need to prevent them at all; they simply ignore them in version control:

__pycache__/
*.pyc

That is often the most practical choice because it keeps the repository clean while preserving import speed during development.

Disable Bytecode Writes for One Run or One Environment

If you really do not want Python to create .pyc files, the smallest-scope option is the -B flag:

python -B app.py

That tells Python not to write bytecode during that invocation. It is handy for one-off scripts, CI commands, or cleanup-sensitive tasks.

If you want the same behavior across a shell session or container, use the environment variable:

export PYTHONDONTWRITEBYTECODE=1
python app.py

On Windows Command Prompt:

set PYTHONDONTWRITEBYTECODE=1
python app.py

This is a good fit for CI pipelines, temporary development shells, or container images where generated cache files add no value.

You can also set the flag in code:

import sys

sys.dont_write_bytecode = True

That works, but it is usually the least clean option because imports that happened earlier in startup may already have written caches. Command-line and environment settings act sooner and are easier to reason about.

Redirect the Cache Instead of Eliminating It

Sometimes the real complaint is not "I never want bytecode," but "I do not want cache files mixed into my project tree." In that case, redirecting the cache can be better than disabling it.

Python supports a dedicated cache root through PYTHONPYCACHEPREFIX:

export PYTHONPYCACHEPREFIX=/tmp/python-cache
python app.py

Now Python still writes bytecode, but it places the cache under the prefix directory instead of scattering __pycache__ folders next to source files. This is useful when you want a clean working directory but still prefer warm import performance.

That option is overlooked surprisingly often. If your concern is repository cleanliness rather than policy, redirecting caches may be the best compromise.

Clean Up Existing Cache Files Safely

Disabling future .pyc creation does not remove old cache files. If the tree is already cluttered, clean it separately.

On Unix-like systems:

find . -type d -name "__pycache__" -prune -exec rm -rf {} +
find . -type f -name "*.pyc" -delete

Run those commands only from the directory you actually intend to clean. They are useful in build artifacts, temporary workspaces, or generated sandboxes, but you do not want to aim them at the wrong path.

Choose the Right Tradeoff

In most normal development environments, keeping .pyc files and ignoring them is the best default. You get faster imports and fewer surprises.

Disable bytecode writing when you have a concrete reason, such as:

• ephemeral CI runs
• tightly controlled build outputs
• read-only or cleanup-sensitive environments
• debugging situations where generated files are distracting

If the issue is only source-tree clutter, redirecting the cache or ignoring it in Git is usually better than disabling it globally for all Python work.

Common Pitfalls

The most common mistake is deleting .pyc files once and forgetting to ignore __pycache__/ and *.pyc. The files simply come back on the next import.

Another issue is setting sys.dont_write_bytecode = True after many modules have already been imported. That does not retroactively undo the cache files that were written earlier.

People also sometimes disable bytecode globally in their shell startup files and then forget about it. Months later, they are confused about slower imports or inconsistent behavior in unrelated projects. Prefer the narrowest scope that solves the actual problem.

Finally, avoid treating .pyc files as inherently bad. They are a normal performance feature. If you do not have a strong reason to turn them off, ignoring them is enough.

Summary

• '.pyc files are bytecode caches, not errors.'
• Use python -B for a one-off run without cache writes.
• Use PYTHONDONTWRITEBYTECODE=1 for a session, environment, or container.
• If you only want a cleaner source tree, consider PYTHONPYCACHEPREFIX instead of disabling caches entirely.
• In many projects, the simplest answer is to ignore __pycache__/ and *.pyc in version control.