Errore irreversibile di Python: Py_Initialize: impossibile ottenere la codifica locale ... SintassiError: sintassi non valida Aborted (core dumped)


16

Ho installato anaconda eseguendo il

bash Anaconda-2.2.0-Linux-x86_64.sh

comando sul mio sistema Ubuntu 14.04, installato correttamente, dopo di che mi è stato chiesto di esportare la mia nuova /home/username/anaconda/binvariabile d'ambiente $ PATH.

In tal modo, sono stato in grado di utilizzare tutte le funzionalità di anaconda, inclusi gli IDE, nonché di utilizzare con successo tutti i comandi basati su conda.

La volta successiva che ho avviato il mio sistema, ogni comando digitato in modo errato vedeva a

Fatal Python error: Py_Initialize: Unable to get the locale encoding
  File "/usr/local/lib/python2.7/encodings/__init__.py", line 123
    raise CodecRegistryError,\
                            ^
SyntaxError: invalid syntax
Aborted (core dumped)

errore. (Tutti i comandi tranne pythonper essere specifici)

Seguendo alcuni post di stackexchange e askubuntu e notando anche che il mio $PYTHONPATHera stato impostato usr/local/lib/python2.7, ho provato a farlo

export PYTHONPATH=$PYTHONPATH:/home/username/anaconda/lib/python2.7

ma non ha aiutato.

Questo mi ha fatto passare attraverso un'intera saga di rimozioni di pacchetti e reinstallazione e, naturalmente, molti aggiornamenti e upgrade, per cercare di risolvere il problema da solo.

conda info -a ritorna:

CIO_TEST: <not set>
CONDA_DEFAULT_ENV: <not set>
CONDA_ENVS_PATH: <not set>
LD_LIBRARY_PATH: <not set>
PATH: /home/username/anaconda/bin:/home/username/Scala-sbt/sbt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/username/bin:/usr/local/java/jdk1.8.0_20/bin
PYTHONHOME: <not set>
PYTHONPATH: /usr/local/lib/python2.7:/home/username/anaconda/bin/python

Il comando

which python

ritorna

/home/username/anaconda/bin/python

e

echo "$PATH"

ritorna

/home/username/anaconda/bin:/home/username/Scala-sbt/sbt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/username/bin:/usr/local/java/jdk1.8.0_20/bin

So che ha a che fare con il modo in cui ho impostato le variabili del percorso, in particolare nella ~/.bashrcquale Anaconda ha anteposto automaticamente la mia cartella / home / username / anaconda / bin alla $PATHvariabile (ciò è accaduto durante una seconda installazione di Anaconda dopo che l'ho rimosso per primo ).

Non ho modificato alcuna altra variabile di ambiente in ~/.profileo ~/.bashrc.


Ho aggiunto la riga di esportazione $ PYTHONPATH alla mia ~/.bashrcprima di riavviare.

Tutte le funzionalità di Anaconda funzionano ora, anche se lo stesso Fatal Python error: Py_Initialize: Unable to get the locale encodingerrore continua a comparire invece del solito errore di comando sconosciuto, per la maggior parte dei comandi errati.

Continuerò a esaminarlo e a modificare la mia risposta (o far riferimento a eventuali risposte esistenti) non appena scoprirò perché ciò accade.

Risposte:


11

Consiglierei di disabilitare PYTHONPATH. Generalmente non è necessario e causa la rottura di queste cose facendo caricare un Python da un altro Python (in questo caso, sembra che il Python 3 del sistema stia provando a caricare qualcosa che è stato scritto per Python 2).


3
Scuse sincere per la risposta tardiva, signore. Disattivando PYTHONPATH, intendi configurarlo manualmente all'avvio ogni volta? Anaconda esegue attualmente Python 2.7.10 e non ho installato Python 3, quindi perché dovrebbe apparire questo errore? Il motivo per cui sto chiedendo è che le informazioni di Conda per le directory del sito dell'utente specificano la variabile PYTHONPATH come PYTHONPATH: /home/usrnme/anaconda/lib/python2.7:/usr/local/lib/python2.7. Se dovessi rimuovere la riga PYTHONPATH: / home / usrnme / anaconda .. dal mio ~ / .bashrc, l'errore continuerebbe a persistere, e anche nessuna delle funzionalità di Anaconda funzionerebbe, fino a quando non la reimposterò.
Samirzach,

3

Ho avuto problemi simili negli ultimi due giorni, quindi ho fatto risalire al modo in cui bash gestisce "comando non trovato". In Ubuntu 14.04 (e Linux Mint 17, che utilizzo gli script 14.04), /etc/bash.bashrc ha la seguente funzione:

if [ -x /usr/lib/command-not-found ]; then
    function command_not_found_handle {
        # check because c-n-f could've been removed in the meantime
        if [ -x /usr/lib/command-not-found ]; then
            /usr/bin/python /usr/lib/command-not-found -- $1
            return $?
        else
           return 127
        fi
    }
fi

Tuttavia, / usr / lib / command-not-found è stato riscritto per Python 3. Gestisce il comando /etc/bash.bashrc con:

if sys.version < '3':                                                       
    # We might end up being executed with Python 2 due to an old            
    # /etc/bash.bashrc.                                                     
    import os                                                               
    if "COMMAND_NOT_FOUND_FORCE_PYTHON2" not in os.environ:                 
        os.execvp("python3", [sys.argv[0]] + sys.argv)

Questo chiama "python3" dal percorso piuttosto che dare il percorso diretto. Per correggere ciò, la riga 22 di / usr / lib / command-not-found dovrebbe essere cambiata da

os.execvp("python3", [sys.argv[0]] + sys.argv)

per

os.execv("/usr/bin/python3", [sys.argv[0]] + sys.argv)

Questo sembra essere un bug con Ubuntu piuttosto che Anaconda. Controllerò per vedere se appare nelle distribuzioni successive.


1

Dopo aver installato python3 nelle posizioni standard e aver realizzato che avevo bisogno di sudo per usarlo, ho installato localmente usando questo nella mia directory home:

python3 -m venv env_py3
source env_py3/bin/activate

Ma ha avuto più errori. Semplicemente disordinare PYTHONPATH sull'istanza di Amazon Linux di AWS ha funzionato perfettamente per me.


0

Il mio problema era un po 'diverso: come un utente, potevo correre python, ma come un altro utente, non (ho avuto lo stesso errore di OP). Alla fine, ho scoperto che i permessi e la proprietà di /usr/lib/python3.5 sono stati fregati. Il motivo era che avevo impostato in modo ricorsivo i permessi e la proprietà su virtualenv, che finiva per modificare anche i target dei link simbolici (targetin /usr/lib/python3.5 ).

Suggerimento: utilizzare strace pythonper capire cosa sta succedendo durante l'avvio di Python. Quando l'ho usato strace, ho potuto vedere chiaramente PERMISSION_DENIED su /usr/lib/python3.5 .



-3

Ho avuto un problema simile su Windows: ho eliminato la variabile di sistema PYTHONHOME. Proverò a tradurre la soluzione in inglese. Risorse del computer> Proprietà> Impostazioni di sistema avanzate> Variabili d'ambiente, cerca la variabile PYTHONHOME ed eliminala.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.