# Heads-up: .pyc magic number change in 3.14.0rc2

**URL:** <https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095>\
**Category:** Core Development\
**Created:** [August 12, 2025, 9:36am UTC](https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095 "2025-08-12T09:36:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\
**Post date:** [August 12, 2025, 9:36am UTC](https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095/1 "2025-08-12T09:36:59Z")

</div>

Hello,  
There’s [a bug](https://github.com/python/cpython/issues/137288) in 3.14.0rc1 code generation that will ~~probably~~ require bumping the importlib magic number. [edit: PR is merged; this is happening]  
This means that if you distribute `.pyc` files, you will need to re-build them with 3.14.0rc2.  
(If you don’t know whether you’re distributing `.pyc` files, you probably aren’t. Wheels on PyPI are generally not affected.)

Long version: If we bump the number, ` __pycache__ /*.pyc` files compiled for rc1 won’t be usable in rc2. Python will re-compile them automatically, so this will only affect you if the user running the code doesn’t have permissions to the ` __pycache__ ` directories – typically, if they’re installed in a read-only, “system-wide” or otherwise shared location. In that case, Python will skip writing the cache, making repeated imports slow. In the past, we also saw security warnings due to failed attemps to write to such “shared” locations.

---

<div class="post-metadata">

**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\
**Post date:** [August 12, 2025, 3:26pm UTC](https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095/2 "2025-08-12T15:26:59Z")

</div>

Wow, glad we caught it now!

---

<div class="post-metadata">

**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\
**Post date:** [August 12, 2025, 5:03pm UTC](https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095/3 "2025-08-12T17:03:17Z")

</div>

Let’s do an extra release candidate for this: [Early 3.14.0 rc2 and extra rc3](https://discuss.python.org/t/early-3-14-0-rc2-and-extra-rc3/102151)

---

<div class="post-metadata">

**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\
**Post date:** [August 14, 2025, 8:03pm UTC](https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095/4 "2025-08-14T20:03:48Z")

</div>

This is now out, please test:

> [@Python 3.14.0rc2 and 3.13.7 are go!](https://discuss.python.org/t/python-3-14-0rc2-and-3-13-7-are-go/102403):
>
> Not one but two expedited releases! tada tadaPython 3.14.0rc2 [It’s](https://www.youtube.com/watch?v=zJpJbL6Pzjo) the final magic_wand penultimate magic_wand 3.14 release candidate! [https://www.python.org/downloads/release/python-3140rc2/](https://www.python.org/downloads/release/python-3140rc2/) Note: rc2 was originally planned for 2025-08-26, but we [fixed a bug](https://discuss.python.org/t/heads-up-pyc-magic-number-change-in-3-14-0rc2/102095) that required bumping the magic number stored in Python bytecode (.pyc) files. This means .pyc files created for rc1 cannot be used for rc2, and they’ll be recompiled. The ABI isn’t changing. Wheels built for rc1 should be fine …