371

What's the "Bad magic number" ImportError in python, and how do I fix it?

The only thing I can find online suggests this is caused by compiling a .py -> .pyc file and then trying to use it with the wrong version of python. In my case, however, the file seems to import fine some times but not others, and I'm not sure why.

The information python's providing in the traceback isn't particularly helpful (which is why I was asking here...), but here it is in case it helps:

Traceback (most recent call last):
  File "run.py", line 7, in <module>
    from Normalization import Normalizer
Noah
  • 21,451
  • 8
  • 63
  • 71

15 Answers15

491

The magic number comes from UNIX-type systems where the first few bytes of a file held a marker indicating the file type.

Python puts a similar marker into its pyc files when it creates them.

Then the python interpreter makes sure this number is correct when loading it.

Anything that damages this magic number will cause your problem. This includes editing the pyc file or trying to run a pyc from a different version of python (usually later) than your interpreter.

If they are your pyc files (or you have the py files for them), just delete them and let the interpreter re-compile the py files. On UNIX type systems, that could be something as simple as:

rm *.pyc

or:

find . -name '*.pyc' -delete

If they are not yours, and the original py files are not provided, you'll have to either get the py files for re-compilation, or use an interpreter that can run the pyc files with that particular magic value.

One thing that might be causing the intermittent nature. The pyc that's causing the problem may only be imported under certain conditions. It's highly unlikely it would import sometimes. You should check the actual full stack trace when the import fails.

As an aside, the first word of all my 2.5.1(r251:54863) pyc files is 62131, 2.6.1(r261:67517) is 62161. The list of all magic numbers can be found in Python/import.c, reproduced here for completeness (current as at the time the answer was posted, has changed since then):

1.5:   20121
1.5.1: 20121
1.5.2: 20121
1.6:   50428
2.0:   50823
2.0.1: 50823
2.1:   60202
2.1.1: 60202
2.1.2: 60202
2.2:   60717
2.3a0: 62011
2.3a0: 62021
2.3a0: 62011
2.4a0: 62041
2.4a3: 62051
2.4b1: 62061
2.5a0: 62071
2.5a0: 62081
2.5a0: 62091
2.5a0: 62092
2.5b3: 62101
2.5b3: 62111
2.5c1: 62121
2.5c2: 62131
2.6a0: 62151
2.6a1: 62161
2.7a0: 62171
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • 7
    Thanks -- this didn't directly help me figure out my problem, but it's nice to know the answer anyways! – Noah Feb 05 '09 at 03:36
  • 1
    How can I check what pyc file causes the issue, I have deleted all pyc files but still getting this error. – sunprophit Jul 30 '13 at 08:12
  • 1
    Perhaps you need 'rm __pycache__/*pyc' now, because the pyc files are now in that folder. – Arpad Horvath -- Слава Україні Jun 02 '16 at 17:30
  • 1
    Thanks! It was happening to me with: ERROR:tornado.general:Cannot load translation for 'es': [Errno 0] Bad magic number: '/app/locale/es/LC_MESSAGES/django.mo'. In fact, it was that the *.mo was not compiled correctly. – ericson.cepeda Aug 17 '16 at 18:14
  • 1
    More extensive list here: https://github.com/google/pytype/blob/master/pytype/pyc/magic.py – Davy Dec 20 '17 at 08:04
  • Excellent explanation – Underoos Oct 15 '21 at 09:22
  • FWIW, I think you can always delete `.pyc` files. Unless I'm missing something (not at all unlikely) it wouldn't matter if it is "yours" or someone else's. `.pyc` are created when some Python module is **imported**. Note that this doesn't happen when a Python module is **executed**. It is just an optimization that obviates the need to perform an interim step before making the module usable. That step will simply be re-performed if the `.pyc` is missing. I'm all ears for a nuance in which any of that is incorrect. – John Carrell Mar 21 '22 at 16:25
  • For me, this pointed me to trying a `git clean -xfd --dry-run ...` in this repo I'm working with. It listed a bunch of *.pyc that needed to be regenerated so I targeted my `git clean ...` towards those. The reason those *.pyc needed to be regenerated was b.c. I checked out a new tag that made the transition from python2 to python3. – solstice333 May 22 '22 at 08:31
  • FYI in Pycharm, you can right click on a folder in the Project pane and hit `Clean Python compiled files` (cf: [docs](https://www.jetbrains.com/help/pycharm/cleaning-pyc-files.html)). – LoneCodeRanger Mar 27 '23 at 14:20
  • 1
    @JohnCarrell: yes, you *can* delete the `pyc` files *if you have the `py` files they can be re-constructed from. I was thinking of the case where someone ships only the `pyc` files, however evil that may be :-). I'll clarify. – paxdiablo Mar 27 '23 at 23:41
70

Deleting all .pyc files will fix "Bad Magic Number" error.

find . -name "*.pyc" -delete
mikemaccana
  • 110,530
  • 99
  • 389
  • 494
akarca
  • 1,456
  • 15
  • 12
  • 8
    It's probably better to use `find . -name "*.pyc" -delete`, as you'll have issues with spaces (and possibly with too long a command line) if you expand all the filenames to pass to `rm`. – Andrew Aylett May 25 '10 at 14:19
  • 36
    IMO thats quite a dangerous script. What if a package was delivered with only .pyc files in order to keep it closed source? Oops, you just deleted the application. – Dan Mantyla Sep 18 '12 at 15:06
  • 4
    Probably best to first run `find . -name "*.pyc" -print` and only then either delete the problematic files manually, and/or run the command above, after verifying you're not doing something regrettable. – michael Aug 11 '16 at 23:45
  • 13
    @DanMantyla Closed source packages deserve deletion anyways. – cat May 11 '17 at 20:17
33

Loading a python3 generated *.pyc file with python2 also causes this error.

the
  • 21,007
  • 11
  • 68
  • 101
jtm
  • 1,535
  • 18
  • 19
  • 7
    This could be a comment, not a answer. – This company is turning evil. Dec 12 '14 at 23:49
  • 3
    @Kroltan yet it is damn good as an answer, better than the accepted one. Concise and to-the-point. – Antony Hatchkins May 06 '16 at 20:55
  • 1
    @AntonyHatchkins At least in my view, this could be a comment on any of the answers suggesting deletion of .pyc. Even though this is one possible *cause*, it doesn't have a different *solution*, so this is redundant. Feel free to disagree, just my opinion. – This company is turning evil. May 06 '16 at 23:30
  • 1
    @Kroltan The 'how to fix' part is pretty obvious here. The cause, that's what really interesting – at least for me – is. I did a lot of mangling with different python 2.x versions and never encountered any incompatibilities between .pyc versions. And this solution says it is python3 vs python2 problem - information missing in the accepted answer. Plus I love short answers (where possible) :) – Antony Hatchkins May 10 '16 at 04:28
  • @AntonyHatchkins, this solution may well say it's a py2/3 issue but that's only *one* possibility and, for that matter, one suggested in the accepted answer (paragraph 4) since its very first version :-) – paxdiablo Jun 03 '16 at 02:45
  • @paxdiablo this solution says there can be other possibilities. From my experience it is highly unlikely to be caused by different 2.x versions. The accepted answer is way too long for me. Many unnecessary details. It would be much more helpful to say under which condition this error arises instead of explaining what magic number is. – Antony Hatchkins Jun 03 '16 at 04:50
  • 1
    @Antony, that's understandable. Myself, I prefer to educate as well as solve the immediate problem (teach a man to fish and all that) but I can see where you're coming from. Cheers. – paxdiablo Jun 03 '16 at 23:48
  • @paxdiablo I appreciate your efforts, and I'm also fond of going into details much deeper than necessary :) In this particular case this answer was more helpful to me, nothing more than that :) – Antony Hatchkins Jun 05 '16 at 12:29
  • This was the cause for me (actually 2.x pyc's ref'd in a 3.x environment), specifically an unrelated app install silently updating my system's python path environment variable (grrr). – mr3 Apr 20 '20 at 18:25
6

Take the pyc file to a windows machine. Use any Hex editor to open this pyc file. I used freeware 'HexEdit'. Now read hex value of first two bytes. In my case, these were 03 f3.

Open calc and convert its display mode to Programmer (Scientific in XP) to see Hex and Decimal conversion. Select "Hex" from Radio button. Enter values as second byte first and then the first byte i.e f303 Now click on "Dec" (Decimal) radio button. The value displayed is one which is correspond to the magic number aka version of python.

So, considering the table provided in earlier reply

  • 1.5 => 20121 => 4E99 so files would have first byte as 99 and second as 4e
  • 1.6 => 50428 => C4FC so files would have first byte as fc and second as c4
Sanjay Chopra
  • 71
  • 1
  • 2
4

This can also be due to missing __init__.py file from the directory. Say if you create a new directory in Django for separating the unit tests into multiple files and place them in one directory then you also have to create the __init__.py file beside all the other files in new created test directory. otherwise it can give error like:

Traceback (most recent call last):
  File "C:\Users\USERNAME\AppData\Local\Programs\Python\Python35\Lib\unittest\loader.py",line 153, in loadTestsFromName
    module = __import__(module_name)
ImportError: bad magic number in 'APPNAME.tests': b'\x03\xf3\r\n'
S.B
  • 13,077
  • 10
  • 22
  • 49
Shahraiz Ali
  • 96
  • 3
3

In my case it was not .pyc but old binary .mo translation files after I renamed my own module, so inside this module folder I had to run

find . -name \*.po -execdir sh -c 'msgfmt "$0" -o `basename $0 .po`.mo' '{}' \;

(please do backup and try to fix .pyc files first)

d9k
  • 1,476
  • 3
  • 15
  • 28
3

"Bad magic number" error also happens if you have manually named your file with an extension .pyc

Deke
  • 4,451
  • 4
  • 44
  • 65
1

I had a strange case of Bad Magic Number error using a very old (1.5.2) implementation. I generated a .pyo file and that triggered the error. Bizarrely, the problem was solved by changing the name of the module. The offending name was sms.py. If I generated an sms.pyo from that module, Bad Magic Number error was the result. When I changed the name to smst.py, the error went away. I checked back and forth to see if sms.py somehow interfered with any other module with the same name but I could not find any name collision. Even though the source of this problem remained a mistery for me, I recommend trying a module name change.

Gábor Paller
  • 175
  • 1
  • 8
0

This is much more efficent than above.

find {directory-of-.pyc-files} -name "*.pyc" -print0 | xargs -0 rm -rf

where {directory-of-.pyc-files} is the directory that contains the compiled python files.

Breezer
  • 483
  • 3
  • 10
ozgurv
  • 9
  • 1
  • 1
    That is in case you have the py files on hand, if not you will need to downgrade the python install. – Leon Fedotov May 29 '10 at 16:15
  • 1
    This is still unsafe for some edge cases. Also why are we doing a recursive delete when we're talking about files? – Jerome Baum Oct 13 '12 at 22:03
  • 1
    Why are you using two processes? Even if find didn't have delete, you could still run `find /dir -name "*.pyc" -exec rm '{}' ';'` – mikemaccana Nov 13 '12 at 15:23
  • 1
    The 'find' command won't work safely for filenames with spaces in if the default -print final operator is used directly by xargs rm. Python doesn't import non-identifier named files like this, but scripts could still cause this to break and they wouldn't be deleted. Generally always safer to use an extra -print0 (zero on the end) on the find command (as the last parameter before the '|' pipe symbol) and then -0 option on xargs (thats a hyphen + zero) to understand the -print0 output before the rm command, when piping find into xargs. – Breezer Nov 27 '15 at 17:33
0

This can also happen if you have the wrong python27.dll file (in case of Windows), to solve this just re-install (or extract) python with the exact corresponding dll version. I had a similar experience.

Ibrahim.H
  • 1,062
  • 1
  • 13
  • 22
0

I just faced the same issue with Fedora26 where many tools such as dnf were broken due to bad magic number for six. For an unknown reason i've got a file /usr/bin/six.pyc, with the unexpected magic number. Deleting this file fix the problem

zedge
  • 1
0

You will need to run this command in every path you have in your environment. 

>>> import sys
>>> sys.path
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/usr/local/lib/python3.6/dist-packages', '/source_code/src/python', '/usr/lib/python3/dist-packages']

Then run the command in every directory here

find /usr/lib/python3.6/ -name "*.pyc" -delete
find /usr/local/lib/python3.6/dist-packages -name "*.pyc" -delete
# etc...
Ahmed
  • 2,825
  • 1
  • 25
  • 39
0

In my case, I've git clone a lib which had an interpreter of 

#!/usr/bin/env python

While python was leading to Python2.7 even though my main code was running with python3.6 ... it still created a *.pyc file for 2.7 version ...

I can say that this error probably is a result of a mix between 2.7 & 3+ versions, this is why cleanup ( in any way you can think of that you're using ) - will help here ...

  • don't forget to adjust those Python2x code -> python 3...
Ricky Levi
  • 7,298
  • 1
  • 57
  • 65
0

So I had the same error : ImportError bad magic number. This was on windows 10

This error was because I installed mysql-connector

So I had to:

pip uninstall mysql-comnector
pip uninstall mysql-connector-python
pip install mysql-connector-python
S.B
  • 13,077
  • 10
  • 22
  • 49
mayaki ujeh
  • 1
-1

Don't delete them!!! Until..........

Find a version on your git, svn or copy folder that works.

Delete them and then recover all .pyc.

That's work for me.

lauralacarra
  • 580
  • 7
  • 10