Python Bytecode Explained (with Real dis Output)

When CPython runs your script, it doesn't execute the text of your .py directly. It compiles the source into an intermediate form called bytecode — a compact sequence of instructions (opcodes) like "load this constant," "call this function," "return." Those instructions are then fed to the Python virtual machine (the evaluation loop inside the interpreter), which runs them.

So the real pipeline is: source `.py` → compile → bytecode (a code object) → the VM executes it. The compile step is fast and automatic, which is why it feels like Python "just runs" your source.

• Bytecode — the opcode instructions themselves (raw bytes).
• Code object — the container the compiler produces: the bytecode plus the constants, names, and variable names it references.
• `.pyc` — a code object serialized to disk so the compile step can be skipped next time.

The standard library ships a disassembler. Point dis.dis() at any function and it prints the bytecode in human-readable form. Here's a small function and its real disassembly:

def add_tax(price, rate=0.2):
    total = price + price * rate
    return round(total, 2)

  5   LOAD_FAST_BORROW_LOAD_FAST_BORROW 0 (price, price)
      LOAD_FAST_BORROW         1 (rate)
      BINARY_OP                5 (*)
      BINARY_OP                0 (+)
      STORE_FAST               2 (total)

  6   LOAD_GLOBAL              1 (round + NULL)
      LOAD_FAST_BORROW         2 (total)
      LOAD_SMALL_INT           2
      CALL                     2
      RETURN_VALUE

Read it top to bottom and it's just your function: load price and rate, multiply, add, store into total; then load round, load total and the constant 2, call, return. That's the whole point — bytecode is a faithful, low-level transcript of your code, not an encrypted version of it.

The bytecode alone isn't enough to run — it references constants and names that live alongside it in the code object. You can compile a snippet and inspect them directly. I compiled a module with a fake API key and a license check:

co_consts (module): ('sk-live-42', <code object check>, None)
co_names  (module): ('API_KEY', 'check')
check.co_consts   : ('PRO-2026',)
check.co_varnames : ('k',)
check.co_code     : 800056005200384800002300   # the raw opcode bytes

Look at co_consts: the string "sk-live-42" and the license value "PRO-2026" are sitting there in plain text. co_names keeps API_KEY and check. The compiler lowered your logic to opcodes, but it did not hide your literals or your names — they're stored as data the bytecode indexes into.

And a code object is exactly what the interpreter runs — you can execute one directly with exec, no source file needed:

exec(code, ns)
ns["check"]("PRO-2026")   # -> True

When Python imports a module, it caches the compiled code object to a .pyc in __pycache__/ so it doesn't have to recompile next time. I compiled a two-line module and dissected the real file — it's 158 bytes: a 16-byte header, then one marshal-serialized code object.

total size        : 158 bytes
header magic (4B) : 2b0e0d0a   -> version tag 3627 (Python 3.14)
bit field   (4B)  : 0          (timestamp-based .pyc)
next 8 bytes      : source mtime + size
rest              : one marshal-serialized code object

That first 4-byte magic number is how Python refuses to load a .pyc built by a different version. It bumps almost every release, because — as we saw — the opcodes themselves change. A few real tags:

People often ship .pyc files (or marshal blobs) believing the source is now hidden. Bytecode is a *different shape*, not a *secret*. Two things I verified on the real file:

• Strings leak in the clear. Searching the raw .pyc bytes for my literals, both SECRET and its value hunter2 are present verbatim — no decompiler required, just a text search.
• The logic disassembles. As the dis output above shows, anyone can read the control flow and constants straight from the bytecode.

And going all the way back to source is a solved problem: a decompiler rebuilds readable .py from the bytecode. You can try it right now — drop a .pyc into our free, in-browser Python .pyc Decompiler (it runs pycdc compiled to WebAssembly, so nothing is uploaded), or read the full walk-through where I decompiled a real .pyc back to source.

That's where actual protection comes in: running the source through the Python Obfuscator renames every identifier, encrypts string literals so they don't sit in co_consts as plain text, and can wrap the whole thing in an encrypted loader — so even the disassembled bytecode gives an attacker nothing readable.