什么是错误的幻数错误?

问题:什么是错误的幻数错误?

什么是python中的“错误魔术数字” ImportError,该如何解决?

我在网上可以找到的唯一东西表明,这是由于编译.py-> .pyc文件,然后尝试将其与错误版本的python一起使用而引起的。但是,就我而言,该文件有时可以很好地导入,而其他时候则不能,并且我不确定为什么。

python在回溯中提供的信息不是特别有用(这就是为什么我在这里询问…的原因),但是在这里它是有帮助的:

Traceback (most recent call last):
  File "run.py", line 7, in <module>
    from Normalization import Normalizer

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

回答 0

幻数来自UNIX类型的系统,其中文件的前几个字节包含一个指示文件类型的标记。

Python pyc在创建文件时会将类似的标记放入其文件中。

然后,python解释器会在加载时确保此数字正确。

任何损坏此幻数的东西都会引起您的问题。这包括编辑pyc文件或尝试pyc从解释器以外的其他版本的python(通常更高版本)运行。

如果它们是您的 pyc文件,只需删除它们,然后让解释器重新编译py文件。在UNIX类型的系统上,这可能很简单:

rm *.pyc

要么:

find . -name '*.pyc' -delete

如果不是您自己的py文件,则必须获取文件以进行重新编译,或者需要具有可以pyc使用该特定魔术值运行文件的解释器。

一件事可能导致间歇性。该pyc是造成该问题可能只在一定条件下进口。有时不太可能导入。导入失败时,您应该检查实际的完整堆栈跟踪吗?

顺便说一句,我所有2.5.1(r251:54863) pyc文件的第一个单词是621312.6.1(r261:67517)62161。所有魔幻数字的列表都可以在中找到Python/import.c,为完整起见,在此复制(此处为发布答案时的最新信息,此后可能已更改):

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

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, 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, you’ll have to either get the py files for re-compilation, or 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, it may have 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

回答 1

删除所有.pyc文件将解决“错误的魔术数字”错误。

find . -name "*.pyc" -delete

Deleting all .pyc files will fix “Bad Magic Number” error.

find . -name "*.pyc" -delete

回答 2

*.pyc使用python2 加载python3生成的文件也会导致此错误。

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


回答 3

将pyc文件放入Windows机器。使用任何十六进制编辑器打开此pyc文件。我使用了免费软件“ HexEdit”。现在读取前两个字节的十六进制值。就我而言,这些是03 f3。

打开calc并将其显示模式转换为Programmer(在XP中为Scientific),以查看十六进制和十进制转换。从单选按钮中选择“十六进制”。首先输入值作为第二个字节,然后输入第一个字节,即f303现在单击“ Dec”(十进制)单选按钮。显示的值是一个对应于python的幻数(又称魔术版本)的值。

因此,考虑先前答复中提供的表

  • 1.5 => 20121 => 4E99,因此文件的第一个字节为99,第二个字节为4e
  • 1.6 => 50428 => C4FC,因此文件的第一个字节为fc,第二个字节为c4

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

回答 4

如果您使用扩展名.pyc手动命名文件,也会发生“错误的魔术数字”错误

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


回答 5

使用非常旧的(1.5.2)实现,我遇到了一个奇怪的错误数字魔术错误的案例。我生成了一个.pyo文件,并触发了错误。奇怪的是,通过更改模块名称解决了该问题。令人反感的名称是sms.py。如果我从该模块生成了一个sms.pyo,则结果是错误的幻数错误。当我将名称更改为smst.py时,错误消失了。我来回检查了一下sms.py是否以某种方式干扰了其他任何同名模块,但找不到任何名称冲突。即使这个问题的根源对我来说仍然是莫名其妙,但我还是建议您尝试更改模块名称。

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.


回答 6

这也可能是由于__init__.py目录中缺少文件。假设如果您在django中创建了一个新目录以将单元测试分为多个文件并将它们放置在一个目录中,那么您还必须__init__.py在新创建的测试目录中的所有其他文件旁边创建该文件。否则会出现类似的错误 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'

This can also be due to missing __init__.py file from the directory. Say if you create a new directory in django for seperating 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'


回答 7

这比上面的要有效得多。

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

哪里{directory-of-.pyc-files}是包含已编译p​​ython文件的目录。

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.


回答 8

在我的情况下,重命名自己的模块后,它不是.pyc旧的二进制.mo翻译文件,因此在此模块文件夹中,我必须运行

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

(请先备份并尝试先修复.pyc文件)

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)


回答 9

如果您使用了错误的python27.dll文件(对于Windows),也会发生这种情况,要解决此问题,只需使用确切的相应dll版本重新安装(或解压缩)python。我也有类似的经历。

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.


回答 10

我只是在Fedora26上遇到过同样的问题,由于六位数的错误魔术数,dnf之类的许多工具都被破坏了。由于未知的原因,我有一个/usr/bin/six.pyc文件,带有意外的幻数。删除此文件可解决问题

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


回答 11

就我而言,我有git clone一个lib,其中包含

#!/usr/bin/env python

尽管python导致Python2.7我的主要代码与python3.6一起运行,但仍导致该*.pyc文件的2.7版本…

我可以说这个错误可能是2.7和3+版本之间混合使用的结果,这就是为什么清理(无论如何都可以认为正在使用)-在这里有帮助…

  • 不要忘记调整那些Python2x代码-> python 3 …

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…

回答 12

不要删除它们!!!直到……….

在您的git,svn或copy文件夹中找到有效的版本。

删除它们,然后恢复所有.pyc。

那对我有用。

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.


回答 13

您将需要在环境中的所有路径中运行此命令。

>>> 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']

然后在每个目录中运行命令

find /usr/lib/python3.6/ -name "*.pyc" -delete
find /usr/local/lib/python3.6/dist-packages -name "*.pyc" -delete
# etc...

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...