Qual é o erro do número mágico ruim?

O que é o ImportError "Número mágico incorreto" em python e como corrigi-lo?

A única coisa que posso encontrar online sugere que isso é causado pela compilação de um arquivo .py -> .pyc e, em seguida, tentando usá-lo com a versão errada do python. No meu caso, no entanto, o arquivo parece importar bem algumas vezes, mas não outras, e não sei por que.

As informações que o python fornece no traceback não são particularmente úteis (e é por isso que eu estava perguntando aqui ...), mas aqui está, caso ajude:

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

O número mágico vem de sistemas do tipo UNIX, nos quais os primeiros bytes de um arquivo mantinham um marcador indicando o tipo de arquivo.

Python coloca um marcador semelhante em seus pycarquivos quando os cria.

Em seguida, o intérprete python garante que esse número esteja correto ao carregá-lo.

Qualquer coisa que danifique esse número mágico causará seu problema. Isso inclui editar o pycarquivo ou tentar executar um pycde uma versão diferente do python (geralmente mais tarde) que o seu intérprete.

Se forem seus pyc arquivos, exclua-os e deixe o intérprete recompilar os pyarquivos. Em sistemas do tipo UNIX, isso pode ser algo tão simples quanto:

rm *.pyc

ou:

find . -name '*.pyc' -delete

Se eles não forem seus, você precisará obter os pyarquivos para recompilação ou um intérprete que possa executar os pycarquivos com esse valor mágico específico.

Uma coisa que pode estar causando a natureza intermitente. O problema pycque está causando o problema pode ser importado apenas sob certas condições. É altamente improvável que às vezes seja importado. Você deve verificar o rastreamento de pilha completa real quando a importação falhar?

Como um aparte, a primeira palavra de todos os meus 2.5.1(r251:54863) pycarquivos é 62131, 2.6.1(r261:67517)é 62161. A lista de todos os números mágicos pode ser encontrada Python/import.caqui, reproduzida aqui para ser completa (atual, no momento em que a resposta foi postada, ela pode ter sido alterada desde então):

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

A exclusão de todos os arquivos .pyc corrigirá o erro "Número mágico inválido".

find . -name "*.pyc" -delete

Carregar um *.pycarquivo gerado em python3 com python2 também causa esse erro.

Leve o arquivo pyc para uma máquina Windows. Use qualquer editor Hex para abrir este arquivo pyc. Eu usei o freeware 'HexEdit'. Agora leia o valor hexadecimal dos dois primeiros bytes. No meu caso, eram 03 f3.

Abra o calc e converta seu modo de exibição para Programmer (Scientific in XP) para ver a conversão Hex e Decimal. Selecione "Hex" no botão de opção. Insira os valores como segundo byte primeiro e depois o primeiro byte, ou seja, f303 Agora clique no botão de opção "Dec" (decimal). O valor exibido é aquele que corresponde ao número mágico, também conhecido como versão do python.

Portanto, considerando a tabela fornecida na resposta anterior

• 1.5 => 20121 => 4E99 para que os arquivos tenham o primeiro byte como 99 e o segundo como 4e
• 1.6 => 50428 => C4FC para que os arquivos tenham primeiro byte como fc e segundo como c4

O erro "número mágico inválido" também ocorre se você tiver nomeado seu arquivo manualmente com uma extensão .pyc

Eu tive um caso estranho de erro de Bad Magic Number usando uma implementação muito antiga (1.5.2). Eu gerei um arquivo .pyo e isso acionou o erro. Estranhamente, o problema foi resolvido alterando o nome do módulo. O nome ofensivo era sms.py. Se eu gerar um sms.pyo a partir desse módulo, o erro Bad Magic Number foi o resultado. Quando mudei o nome para smst.py, o erro desapareceu. Eu verifiquei para frente e para trás para ver se o sms.py de alguma forma interferia em qualquer outro módulo com o mesmo nome, mas não encontrei nenhuma colisão de nomes. Embora a origem desse problema permaneça um mistério para mim, recomendo tentar uma alteração no nome do módulo.

Isso também pode ocorrer devido à falta de __init__.pyarquivo no diretório. Digamos que se você criar um novo diretório no django para separar os testes de unidade em vários arquivos e colocá-los em um diretório, também será necessário criar o __init__.pyarquivo ao lado de todos os outros arquivos no novo diretório de teste criado. caso contrário, pode dar erro como 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'

Isso é muito mais eficaz do que acima.

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

onde {directory-of-.pyc-files}é o diretório que contém os arquivos python compilados.

No meu caso, não eram mais do que arquivos de tradução .pycbinária antigos .modepois que renomeei meu próprio módulo, portanto, dentro desta pasta do módulo, tive que executar

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

(faça backup e tente corrigir os .pycarquivos primeiro)

Isso também pode acontecer se você tiver o arquivo python27.dll errado (no caso do Windows), para resolver isso basta reinstalar (ou extrair) o python com a versão exata da dll correspondente. Eu tive uma experiência parecida.

Eu apenas enfrentei o mesmo problema com o Fedora26, onde muitas ferramentas como o dnf foram quebradas devido ao número mágico ruim para seis. Por um motivo desconhecido, eu tenho um arquivo /usr/bin/six.pyc, com o número mágico inesperado. A exclusão deste arquivo corrige o problema

No meu caso, eu tenho git cloneuma biblioteca que tinha um intérprete de

#!/usr/bin/env python

Embora pythonestivesse levando Python2.7embora meu código principal estivesse sendo executado com python3.6 ... ele ainda criou um *.pycarquivo para a 2.7versão ...

Posso dizer que esse erro provavelmente é resultado de uma mistura entre as versões 2.7 e 3+, é por isso que a limpeza (de qualquer forma que você possa pensar que está usando) - ajudará aqui ...

• não se esqueça de ajustar o código Python2x -> python 3 ...

Não os apague !!! Até..........

Encontre uma versão na sua pasta git, svn ou copy que funcione.

Exclua-os e depois recupere todos os .pyc.

Isso é trabalho para mim.

Você precisará executar este comando em todos os caminhos existentes em seu ambiente.

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

Em seguida, execute o comando em todos os diretórios aqui

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