2017-02-17 3 views
0

Verwenden einer Debian-basierten Linux-Distribution (Kali) für Python-Programmierung (beachten Sie, dass ich sehr neu für Linux bin, hatte es für weniger als 2 Monate). Installierte Python und GitKraken wie gewohnt mit apt-get install.Linux Terminal ./code.py arbeitet mit Python 2.7.13, während die IDLE verwendet Python 3.5.3

Begann glücklich Codieren mit der 3.5.3 IDLE, aber wenn ich versuchte, pip Befehle verwenden, um Module zu installieren (all dies als root-Benutzer), fand ich die Installation zu /usr/local/lib/python2.7/dist-packages statt Python 3.5.3 /usr/local/lib/python3.5/dist-packages).

Wenn ich pip install module verwendete, installierte es alle Module an der Position 2.7. Da das Terminal standardmäßig 2,7 verwendete (aus welchem ​​Grund auch immer), lief die Verwendung von ./code.py immer mit Python 2.7, aber ich schrieb den Code für Python 3.5 (nicht die Version, für die die Module installiert waren).

Ich sah einige andere Antworten auf dieser Website für ähnliche Probleme, wo Sie neue Module installieren und die PYTHONPATH Variable ändern und Aliasnamen zuweisen müssen, aber es vermasselte mehr Sachen. Jetzt gibt echo $PYTHONPATH nichts zurück, und pip wird immer noch in Python 2.7 installiert.

Ich habe apt-get verwendet, um python-pip3 zu installieren, und ich benutze den pip3-Befehl, um Module zu installieren, aber immer wenn ich ./code.py (meine Hauptmethode zum Ausführen von Code) verwende, verwendet es immer noch Python 2.7. Wie kann ich das ändern?

+0

Wenn Sie 'pip3' haben, dann versuchen' python3 code.py' zu laufen –

Antwort

1

Bearbeiten Sie die shebang in der ersten Zeile von code.py zu Ihrem Python 3.5 binären Punkt, z.B .:

#!/usr/bin/env python3 

Oder wenn es nicht so python3 Figur verknüpft ist waren aus Ihrer Python 3.5 binär ist und verwenden diese.

+0

Ursprünglich hatte '#!/Usr/bin/python', musste am Ende eine 3,5 hinzufügen. Jetzt (mit Pseudonymen für 'pip' und' python') läuft alles gut. – JoshuaS3

+0

Die Verwendung von env wie in der Antwort ist vorzuziehen, weil es portabler ist - der Installationsort von env ist über Unix-Systeme und Linux-Distributionen hinweg gut standardisiert, der Speicherort von (und genauen Unterversionen) von Python ist nicht. '/ usr/bin/env python3' arbeitet mit größerer Wahrscheinlichkeit auf einem anderen System als'/usr/bin/python3.5'. Selbst wenn das andere System 'python3' im Pfad hat, könnte es in'/bin' oder '/ usr/local/bin' sein und es könnte' python3.6' oder ein anderer Name sein, usw. – zstewart