Erreur fatale Python: Py_Initialize: impossible d'obtenir l'encodage des paramètres régionaux ... SyntaxError: syntaxe non valide abandonnée (core dumped)


16

J'ai installé anaconda en exécutant le

bash Anaconda-2.2.0-Linux-x86_64.sh

sur mon système Ubuntu 14.04, qui s'est installé avec succès, après quoi on m'a demandé d'exporter ma nouvelle /home/username/anaconda/binvariable d'environnement $ PATH.

Ce faisant, j'ai pu utiliser toutes les fonctionnalités d'anaconda, y compris les IDE, ainsi que toutes les commandes basées sur conda.

La prochaine fois que j'ai démarré mon système, chaque commande manquée a vu un

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)

Erreur. (Toutes les commandes sauf pythonpour être spécifiques)

En suivant quelques messages stackexchange et askubuntu et en notant également que mon $PYTHONPATHavait été défini sur usr/local/lib/python2.7, j'ai essayé de

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

mais cela n'a pas aidé.

Cela m'a fait traverser toute une saga de suppressions et de réinstallations de packages, et bien sûr, de nombreuses mises à jour et mises à niveau, pour essayer de résoudre le problème par moi-même.

conda info -a Retour:

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

La commande

which python

Retour

/home/username/anaconda/bin/python

et

echo "$PATH"

Retour

/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

Je sais que cela a quelque chose à voir avec la façon dont je définis les variables de chemin, en particulier dans le ~/.bashrcdossier dans lequel Anaconda a automatiquement ajouté mon dossier / home / username / anaconda / bin à la $PATHvariable (cela s'est produit lors d'une deuxième installation d'Anaconda après l'avoir supprimé en premier). ).

Je n'ai pas modifié toute autre variable d'environnement dans les deux ~/.profileou ~/.bashrc.


J'ai ajouté la ligne d'exportation $ PYTHONPATH à mon ~/.bashrcavant de redémarrer.

Toutes les fonctionnalités d'Anaconda fonctionnent maintenant, bien que la même Fatal Python error: Py_Initialize: Unable to get the locale encodingerreur continue de s'afficher au lieu de l'erreur de commande inconnue habituelle, pour la plupart des commandes mal typées.

Je continuerai à examiner cela et à modifier ma réponse (ou à me référer aux réponses existantes, le cas échéant) dès que je découvrirai pourquoi cela se produit.

Réponses:


11

Je recommanderais de désactiver PYTHONPATH. Il n'est généralement pas nécessaire, et il provoque des ruptures comme ceci en faisant charger un Python à partir d'un autre Python (dans ce cas, il semble que Python 3 du système essaie de charger quelque chose qui a été écrit pour Python 2).


3
Sincères excuses pour la réponse tardive, monsieur. En désarmant le PYTHONPATH, voulez-vous dire le configurer manuellement au démarrage à chaque fois? Anaconda exécute actuellement Python 2.7.10 et je n'ai pas installé Python 3, alors pourquoi cette erreur apparaîtrait-elle? La raison pour laquelle je demande est que les informations de Conda pour les répertoires du site utilisateur spécifient la variable PYTHONPATH comme PYTHONPATH: /home/usrnme/anaconda/lib/python2.7:/usr/local/lib/python2.7. Si je dois supprimer la ligne PYTHONPATH: / home / usrnme / anaconda .. de mon ~ / .bashrc, l'erreur persisterait et aucune des fonctionnalités d'Anaconda ne fonctionnerait jusqu'à ce que je la redéfinisse.
samirzach

3

J'ai eu des problèmes similaires au cours des deux derniers jours, je l'ai donc retracée à la façon dont bash gère la "commande introuvable". Dans Ubuntu 14.04 (et Linux Mint 17, dont j'utilise les scripts 14.04), /etc/bash.bashrc a la fonction suivante:

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

Cependant, / usr / lib / command-not-found a été réécrit pour Python 3. Il gère la commande /etc/bash.bashrc avec:

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)

Cela appelle "python3" à partir du chemin plutôt que de donner le chemin direct. Pour corriger cela, la ligne 22 de / usr / lib / command-not-found doit être modifiée de

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

à

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

Cela semble être un bug avec Ubuntu plutôt qu'avec Anaconda. Je vais vérifier si cela apparaît dans les distributions ultérieures.


1

Après avoir installé python3 dans les emplacements standard et réalisé que j'avais besoin de sudo pour l'utiliser, j'ai installé localement en utilisant ceci dans mon répertoire personnel:

python3 -m venv env_py3
source env_py3/bin/activate

Mais avait plus d'erreurs. Désinstaller simplement PYTHONPATH sur l'instance Amazon Linux d'AWS a fonctionné très bien pour moi.


0

Mon problème était un peu différent: en tant qu'utilisateur, je pouvais courir python, mais en tant qu'autre utilisateur, non (j'ai eu la même erreur que OP). Enfin, j'ai découvert que les autorisations et la propriété de /usr/lib/python3.5 étaient vissées. La raison en était que j'avais défini récursivement les autorisations et la propriété sur virtualenv, ce qui a fini par modifier les cibles du lien symbolique (targetin /usr/lib/python3.5 ) également.

Astuce: Utilisez strace pythonpour comprendre ce qui se passe pendant le démarrage de Python. Quand j'ai utilisé strace, je pouvais clairement voir PERMISSION_DENIED sur /usr/lib/python3.5 .



-3

J'ai eu un problème similaire sur Windows - j'ai supprimé la variable système PYTHONHOME. J'essaierai de traduire la solution en anglais. Poste de travail> Propriétés> Paramètres système avancés> Variables d'environnement, recherchez la variable PYTHONHOME et supprimez-la.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.