Can You Decompile a Python 3.15 `.pyc`? (Tested)

API_KEY = "sk-demo-7c1f2a"
def check(user, key):
    if key == "PRO-2026":
        return f"welcome {user}"
    return "access denied"
print(check("mithun", "PRO-2026"))

I compiled it with 3.15.0's py_compile. The file starts with 52 0e 0d 0a, magic number 3666, which identifies Python 3.15 (3.14 is 3627; the full table is in fix "bad magic number"). For real-world code I also used six modules from 3.15's own standard library (fnmatch, base64, textwrap, json.decoder, functools and difflib), which the official Windows download ships as 3.15 .pyc files.

$ pycdc s315.pyc
Bad MAGIC!
Could not load file s315.pyc

$ uncompyle6 s315.pyc
# Unknown magic number 3666 in s315.pyc

$ decompyle3 s315.pyc
Unknown magic number 3666 in s315.pyc

No surprise: pycdc's newest commit is from April 2026, and uncompyle6 and decompyle3 stopped at Python 3.8 and 3.9 years ago. The .pyc isn't damaged or protected; these tools simply don't know version 3666. Support for a new CPython release always arrives late, because every new opcode has to be mapped by hand. For how pycdc behaves on the versions it does support, see the tested pycdc guide.

A .pyc is a 16-byte header plus a marshal-serialized code object, so Python's own marshal and dis modules can read it with no decompiler at all:

import marshal, dis

with open("s315.pyc", "rb") as f:
    f.read(16)                       # 16-byte header
    code = marshal.load(f)

def strings(c):
    for k in c.co_consts:
        if isinstance(k, str):
            yield k
        elif hasattr(k, "co_consts"):
            yield from strings(k)

print(list(strings(code)))
check = next(k for k in code.co_consts if hasattr(k, "co_code"))
for ins in dis.get_instructions(check):
    if ins.opname in ("LOAD_CONST", "COMPARE_OP", "RETURN_VALUE", "POP_JUMP_IF_FALSE"):
        print(f"{ins.opname:18} {ins.argrepr}")

['sk-demo-7c1f2a', 'PRO-2026', 'welcome ', 'access denied', 'mithun', 'PRO-2026']
LOAD_CONST         'PRO-2026'
COMPARE_OP         bool(==)
POP_JUMP_IF_FALSE  to L1
LOAD_CONST         'welcome '
RETURN_VALUE
LOAD_CONST         'access denied'
RETURN_VALUE

Every string, the license check and both branches, with no decompiler installed.

Our free .pyc Decompiler detects 3.15 from the magic number and runs its deeper reconstruction pass, which rebuilds each function and checks it by recompiling it and comparing the bytecode. The test file came back complete, both branches included, with every function verified:

# Decompiled with https://pyobfuscate.dev

API_KEY = 'sk-demo-7c1f2a'
def check(user, key):
    if key == 'PRO-2026':
        return f'welcome {user}'
    else:
        return 'access denied'
print(check('mithun', 'PRO-2026'))

Real modules are harder. Here's what came back for the six standard-library files (a code object is a function, class body, lambda or comprehension):

Every module came back with all its function definitions; the unverified parts are best-effort reconstructions, and the page marks the result as partial when that happens. For comparison I compiled the same source files with 3.14 and 3.15: fnmatch, textwrap and json.decoder verified 90%, 94% and 100% on 3.14, against 73%, 67% and 69% on 3.15. So 3.15 works today, but support is newer: expect a few more partial functions for now.

"No decompiler supports my version yet" isn't protection: the strings and logic came straight out with two standard-library calls, and a full decompiler already rebuilds most of it. The usual advice holds:

1. Obfuscate the source before you compile or ship it. I ran 10 test programs through our Python Obfuscator (both modes, 3 seeds each) and executed all 90 outputs on Python 3.15.0: every one printed exactly the same output as the original. Code that uses syntax new in 3.15, such as lazy import (PEP 810), is supported too (tested 24 October 2026); in the protected output those imports load at startup instead of lazily, and the program behaves the same.
2. Keep real secrets off the client. A hard-coded key sits in co_consts in plain text on every version; load it from the environment or a backend (protecting API keys in Python).
3. For the strongest bar, compile to a native module (Cython or Nuitka), so there is no code object to marshal.load at all. See PyArmor vs Nuitka vs Cython for what each one hides.