Was ist der schlechte magische Zahlenfehler?

Was ist der ImportError "Bad Magic Number" in Python und wie behebe ich ihn?

Das einzige, was ich online finden kann, ist, dass dies dadurch verursacht wird, dass eine .py -> .pyc-Datei kompiliert und dann versucht wird, sie mit der falschen Python-Version zu verwenden. In meinem Fall scheint die Datei jedoch einige Male gut zu importieren, andere jedoch nicht, und ich bin mir nicht sicher, warum.

Die Informationen, die Python im Traceback bereitstellt, sind nicht besonders hilfreich (weshalb ich hier gefragt habe ...), aber hier ist es für den Fall, dass es hilft:

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

Die magische Zahl stammt von Systemen vom Typ UNIX, bei denen die ersten Bytes einer Datei eine Markierung enthielten, die den Dateityp angibt.

Python fügt seinen pycDateien beim Erstellen einen ähnlichen Marker hinzu .

Dann stellt der Python-Interpreter sicher, dass diese Nummer beim Laden korrekt ist.

Alles, was diese magische Zahl beschädigt, wird Ihr Problem verursachen. Dies umfasst das Bearbeiten der pycDatei oder den Versuch, eine pycvon einer anderen Python-Version (normalerweise später) als Ihr Interpreter auszuführen .

Wenn es sich um Ihre pyc Dateien handelt, löschen Sie sie einfach und lassen Sie den Interpreter die pyDateien neu kompilieren . Auf UNIX-Systemen kann dies so einfach sein wie:

rm *.pyc

oder:

find . -name '*.pyc' -delete

Wenn sie nicht Ihnen gehören, müssen Sie entweder die pyDateien zur Neukompilierung oder einen Interpreter abrufen, der die pycDateien mit diesem bestimmten magischen Wert ausführen kann .

Eine Sache, die die intermittierende Natur verursachen könnte. Das pycProblem kann möglicherweise nur unter bestimmten Bedingungen importiert werden. Es ist höchst unwahrscheinlich, dass es manchmal importiert wird. Sie sollten die tatsächliche vollständige Stapelverfolgung überprüfen, wenn der Import fehlschlägt.

Abgesehen davon ist das erste Wort aller meiner 2.5.1(r251:54863) pycDateien 62131, 2.6.1(r261:67517)ist 62161. Die Liste aller magischen Zahlen finden Sie in Python/import.c, der Vollständigkeit halber hier wiedergegeben (aktuell zum Zeitpunkt der Veröffentlichung der Antwort, möglicherweise seitdem geändert):

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

Durch das Löschen aller .pyc-Dateien wird der Fehler "Bad Magic Number" behoben.

find . -name "*.pyc" -delete

Das Laden einer von Python3 generierten *.pycDatei mit Python2 verursacht ebenfalls diesen Fehler.

Bringen Sie die Pyc-Datei zu einem Windows-Computer. Verwenden Sie einen beliebigen Hex-Editor, um diese Pyc-Datei zu öffnen. Ich habe die Freeware 'HexEdit' verwendet. Lesen Sie nun den Hex-Wert der ersten beiden Bytes. In meinem Fall waren dies 03 f3.

Öffnen Sie calc und konvertieren Sie den Anzeigemodus in Programmer (Scientific in XP), um die Hex- und Dezimalkonvertierung anzuzeigen. Wählen Sie "Hex" aus dem Optionsfeld. Geben Sie zuerst Werte als zweites Byte und dann als erstes Byte ein, dh f303. Klicken Sie nun auf das Optionsfeld "Dez" (Dezimal). Der angezeigte Wert entspricht der magischen Zahl, auch bekannt als Python-Version.

In Anbetracht der Tabelle in der vorherigen Antwort

• 1.5 => 20121 => 4E99, sodass Dateien das erste Byte als 99 und das zweite als 4e haben würden
• 1.6 => 50428 => C4FC, sodass Dateien das erste Byte als fc und das zweite als c4 haben

Der Fehler "Bad Magic Number" tritt auch auf, wenn Sie Ihre Datei manuell mit der Erweiterung .pyc benannt haben

Ich hatte einen seltsamen Fall eines Bad Magic Number-Fehlers mit einer sehr alten (1.5.2) Implementierung. Ich habe eine .pyo-Datei generiert, die den Fehler ausgelöst hat. Seltsamerweise wurde das Problem durch Ändern des Modulnamens gelöst. Der beleidigende Name war sms.py. Wenn ich aus diesem Modul eine sms.pyo generiert habe, war der Fehler "Bad Magic Number" die Folge. Als ich den Namen in smst.py änderte, verschwand der Fehler. Ich habe hin und her überprüft, ob sms.py ein anderes Modul mit demselben Namen irgendwie gestört hat, aber ich konnte keine Namenskollision finden. Obwohl die Ursache dieses Problems für mich weiterhin ein Rätsel war, empfehle ich, eine Änderung des Modulnamens zu versuchen.

Dies kann auch an einer fehlenden __init__.pyDatei im Verzeichnis liegen. Angenommen, Sie erstellen in Django ein neues Verzeichnis, um die Komponententests in mehrere Dateien aufzuteilen und in einem Verzeichnis __init__.pyabzulegen. Dann müssen Sie die Datei neben allen anderen Dateien im neu erstellten Testverzeichnis erstellen . Andernfalls kann es zu Fehlern kommen 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'

Dies ist viel effizienter als oben.

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

Wo {directory-of-.pyc-files}ist das Verzeichnis, das die kompilierten Python-Dateien enthält?

In meinem Fall waren es .pycnur alte binäre .moÜbersetzungsdateien, nachdem ich mein eigenes Modul umbenannt hatte, also musste ich in diesem Modulordner ausführen

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

(Bitte sichern Sie und versuchen Sie zuerst, die .pycDateien zu reparieren. )

Dies kann auch passieren, wenn Sie die falsche Datei python27.dll haben (im Fall von Windows). Um dies zu lösen, installieren Sie Python einfach neu (oder extrahieren Sie es) mit der genau entsprechenden DLL-Version. Ich hatte eine ähnliche Erfahrung.

Ich hatte gerade das gleiche Problem mit Fedora26, bei dem viele Tools wie dnf aufgrund einer schlechten magischen Zahl für sechs defekt waren. Aus einem unbekannten Grund habe ich eine Datei /usr/bin/six.pyc mit der unerwarteten magischen Nummer. Das Löschen dieser Datei behebt das Problem

In meinem Fall habe ich git cloneeine Bibliothek, die einen Dolmetscher von hatte

#!/usr/bin/env python

Während dies pythondazu führte, dass Python2.7mein Hauptcode mit Python3.6 ausgeführt wurde, wurde immer noch eine *.pycDatei für die 2.7Version erstellt ...

Ich kann sagen, dass dieser Fehler wahrscheinlich auf eine Mischung aus Versionen 2.7 und 3+ zurückzuführen ist. Aus diesem Grund hilft die Bereinigung (in jeder Hinsicht, die Sie sich vorstellen können, dass Sie sie verwenden) hier ...

• Vergessen Sie nicht, diesen Python2x-Code anzupassen -> Python 3 ...

Lösche sie nicht !!! Bis..........

Suchen Sie eine Version in Ihrem Git-, SVN- oder Kopierordner, die funktioniert.

Löschen Sie sie und stellen Sie dann alle .pyc wieder her.

Das ist Arbeit für mich.

Sie müssen diesen Befehl in jedem Pfad ausführen, den Sie in Ihrer Umgebung haben.

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

Führen Sie dann den Befehl in jedem Verzeichnis hier aus

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