Python Interpreter / Umgebung | Zusatz Anaconda

[Findus.]

Hallo liebes Forum,

erstmal möchte ich mir kurz vorstellen, ich bin Findus und komme aus Bielefeld. Tatsächlich bin ich gerade neu ins Forum dazu gestoßen, beschäftige mich nun seit ca. September 2020 mit Python also ein kompletter Neuling. Dieses Forum möchte ich gerne langfristig nutzen und hoffe natürlich, dass ich irgendwann ebenfalls Ratschläge geben kann.

Ich bin mit dem Buch "Einstieg in Python" angefangen und habe dieses durchgearbeitet. Nebenbei habe ich erste kleine Abfragen im Finanzbereich geschrieben. Ganz simple Sachen wie Abfragen auf Yahoo oder aber mit Hilfe von Video Tools sowas wie Charts mit Pivorpunkten. Letzteres folgte aber lediglich zu 5% in Eigenarbeit. Das Ganze mache ich in der IDE Pycharm

Nun habe ich eine Frage nachdem ich die Suchfunktion erfolglos ausprobiert habe.
- Leider gab es dazu kein Kapitel in dem Buch. -

Umgebungsvariabeln & Umgebungen in Python.

Ich bin leider nicht zu sehr IT affin. In Laienworten habe ich das jetzt so verstanden. Eine Umgebunsvariabel ist eine gesondert gespeicherte Variable die von mehreren Programmen genutzt wird. Eine Shell wie Python greift dabei auf diese Variabel zurück. Ist das so ungefähr richtig?

• Jetzt gibt es einen Interpreter den Python benötigt um die Codezeilen direkt lesen zu können, ok. Davon habe ich 2, einen scheinbar allgemeinen Interpreter (nur Angabe des Pfades der Umgebungsvariabel) und einen der sich auf mein erstes Projekt (Projektname im Pfad) bezieht. Gibt es hier igrndwelche Unterschiede? Macht es Sinn mehrere Interpreter zu besitzen?

Meine erste Überlegung nein, allein schon weil ich dann immer wieder alle Liabraries neu installieren müsste. Ein Interpreter ist in sich geschlossen oder? Ich meine, wenn ich Interpreter 1 Panda und Numpy hinzufüge habe ich diese nicht auch gleichzeitig im Interpreter2?

Ich habe mich jetzt weiterhin für einen Udemy Kurs angemeldet. Hierzu wird über Jupyter die Umgebung Anaconda verwendet. Ich versuche gerade dies über pycharm abzubilden. Die Anaconda Umgebung ist dabei schon aktiviert. Nun habe ich auch eine Anaconda Umgebung (Base) sowie den Interpreter. Ist es korrekt, dass ich hier wie in Punkt 1 wieder alle Liabries neu installieren müsste? Hintergrund: Die Anaconda Umgebung brauche ich erstmalnur für den Kurs. Hauptanliegen sind die Finance Codes. Dabei fällt mir halt auf, dass sowas wie yfinance plötzlich gar nicht mehr als Modul gefunden werden kann.

so sieht es jetzt über Anaconda Prompt aus:

base * C:\Users\Findus\anaconda3
pythonProject C:\Users\Findus\anaconda3\envs\pythonProject

Meine ganzen versuchten Liabiries die ich versucht habe in Anaconda zu implementieren sind auch wie folgt gescheitert.

Package jupyterlab_widgets conflicts for:
ipywidgets -> jupyterlab_widgets[version='>=1.0.0']
jupyter -> ipywidgets -> jupyterlab_widgets[version='>=1.0.0']
_ipyw_jlab_nb_ext_conf -> ipywidgets -> jupyterlab_widgets[version='>=1.0.0']

Package backports.shutil_which conflicts for:
terminado -> pywinpty -> backports.shutil_which
pywinpty -> backports.shutil_which

Entschuldigt die vielen Fragen aber diese Basissachen interessieren mich wirklich um Python in seiner Wirkung besser verstehen zu können.

Vielen Dank

Findus

[__blackjack__]

@Findus.: Umgebungsvariablen und Umgebungen sind erst einmal zwei getrennte Konzepte, auch wenn Umgebungen, wenn wir hier von `venv` & Co reden, unter anderem Umgebungsvariablen benutzen um die Funktionalität bereit zu stellen.

Umgebungsvariablen sind ein Konzept vom Betriebssystem. Man kann die für Prozesse setzen und die sind dann für den Prozess und alle (auch indirekten) Kindprozesse abfragbar. Das Betriebssystem selbst benutzt Umgebungsvariablen wie PATH, wo eine reihe von Pfaden drin stehen in denen nach ausführbaren Dateien und DLLs gesucht wird. Und manchmal haben Programme oder Programmiersprachen Umgebungsvariablen die sie Abfragen und damit irgend etwas machen. Bei Python kann man beispielsweise über die Umgebungsvariable PYTHONPATH beeinflussen wo Python nach Modulen sucht. Das können dann Umgebungen (`venv` & Co) verwenden um Projekte voneinander zu trennen.

Auf die Umgebungsvariablen des Prozesses kannst Du von Python aus über `os.environ` zugreifen. Da wird das über eine API die wie ein Wörterbuch (`dict`) aussieht, zur Verfügung gestellt.

Eine Umgebungsvariable die es auf den meisten Betriebssystemen immer gibt, ist beispielsweise PATH. Kannst Dir das bei Dir ja mal mit ``print(os.environ["PATH"])`` ausgeben lassen. `os` natürlich vorher importieren.

Es macht Sinn mehrere Interpreter zu besitzen wenn man mit mehreren Versionen von Python arbeiten will oder muss. Zum Beispiel weil man noch Software hat die noch Python 2 verwendet, oder um zu schauen ob die eigenen Programme auch mit der allerneuesten Python-Version noch laufen. Bei Projekten/Bibliotheken die von vielen Leuten verwendet werden, lassen die Entwickler beipielsweise in der Regel die Unittests immer mindestens mit allen aktuell unterstützten Python-Versionen laufen. Also momentan 3.6, 3.7, 3.8, und 3.9. Und dann vielleicht auch noch mit der aktuellen in der Entwicklung befindlichen Version oder zumindest mit Beta-Versionen/Release Candidates die offiziell verfügbar sind.

Bei `venv` muss ein Interpreter im Projekt nicht zwingen ein anderer sein, denn zumindest bei Dateisystemen die symbolische Links können, ist das in der Regel einfach nur ein Link auf den tatsächlichen Interpreter.

Das man für jedes `venv` die Bibliotheken neu installiert ist gerade der Sinn von `venv`-Umgebungen, also in sofern *muss* dass Sinn machen, sonst gäbe es das Konzept nicht. Du installierst da nicht nur Pandas und Numpy sondern Pandas und Numpy jeweils in einer bestimmten Version. Nicht jedes Projekt/Programm kommt aber mit jeder Version von einer Bibliothek klar. Und das aktualisieren einer Bibliothek kann andere Bibliotheken und Programme deswegen unbrauchbar machen.

Denn ”Spass” mit Versionskonflikten beschreibst Du dann ja gleich selbst noch. Genau dafür sind die virtuellen Umgebungen da.

Der Interpreter liest übrigens nicht die Codezeilen. Das macht vorher der Compiler und übersetzt den Quelltext in Bytecode, der dann vom Interpreter abgearbeitet wird. Also zumindest bei CPython ist das so, also der Python-Implementierung die man bei python.org bekommt. Im Gegensatz zu Java gehört der Bytecode (noch) nicht fest zur Sprachspezifikation von Python.

[Findus.]

Vielen Dank @__blackjack__ für die Zeit die du dir genommen hast.

Das hat mir sehr geholfen. Ich möchte dann nochmal auf ein paar Punkte eingehen wenn es ok ist.

1) Interpreter: Code --> Compiler-->Umformug in Bytes --> Interpreter (so habe ich das jetzt verstanden).

2) Path: Wieso benötigt Python denn überhaupt einen Path? Wieso funktioniert es nicht einfach wie ein "normales" "geschlossenes" Programm wie Photohop, Alteryx etc. ?

3) mehrfacher Interpreter: Ok, für den Laien sollte aber vermutlich ein Interpreter ausreichend sein? Gerade am Anfang?

Denn ich habe jetzt 3:

Python 3.9 dieser greift auf den Ordner Python zu
Anaconda 3.8(Python Projekt) dieser greift in den Ordner Anaconda in den Unterordner envs\python.exe
Anaconda 3.8 Ordner Anaconda, Unterornder anaconda3\python.exe

Das irritiert mich ein wenig. Kann man hier direkt schon Fehler erkennen? Ich habe es jetzt herausgefunden wie ich wieder auf die ganz normales Standbibiotheken zugreifen kann indem ich gganz einfach wieder für das jeweilige File in Pycharm über Settings auf den Interpreter Python 3.9 umstelle. Zuvor bin ich immer über Preferences gegangen --> Manage for new Projects. Es hat mich immer schon irritiert wieso man den Interpreter immer nur für ein neues Projekt umändern kann. Das hat mich jetzt tatsächlich 4 Monate gekostet.

Ich muss für mich auch noch klären wieso es überhaupt Anaconda benötigt.

[__deets__]

Zu 2: auch C/C++ und anderer native Programmiersprachen nutzen solche Mechanismen. Nur weil du sie nicht kennst, heißt es nicht, dass die nicht da sind. PATH gilt zb auch für DLL Lookup, und der Begriff “DLL-Hölle” beschreibt eine Vielzahl von Problemen, die man mit diesem System haben kann. Dann gibts noch die VCC runtime, die auch mal fehlen/falsch sein kann, etc pp.

[__blackjack__]

@Findus.: Ad 1: Das sieht richtig aus.

Ad 2: Welchen meinst Du jetzt? PATH braucht das Betriebssystem um Programme und DLLs zu finden, das heisst das braucht Python nicht selbst, aber das braucht man für *jedes* Programm. Und wenn das Programm seinerseits DLLs benutzt (machen fast alle) oder andere Programme startet, dann ist da auch jeweils PATH involviert sofern das Programm den DLL- oder Programmnamen nicht als absoluten Pfad angibt.

PYTHONPATH *braucht* Python nicht, aber man *kann* diese Variable setzen. Zum Beispiel um Packages hinzuzufügen ohne sie installieren zu müssen.

Es gibt da übrigens nicht wenige Umgebungsvariablen: https://docs.python.org/3.6/using/cmdli ... -variables

Wie __deets__ schon schrieb: Umgebungsvariablen werden auch von vielen anderen Programmen verwendet.

Auf dem Rechner an dem ich gerade sitze sind 69 Umgebungsvariablen für die Python-Shell definiert die von verschiedenen Programmen verwendet werden:

Code: Alles auswählen

In [292]: len(os.environ)                                                       
Out[292]: 69

In [293]: sorted(os.environ.keys())                                             
Out[293]: 
['COLORFGBG',
 'COLORTERM',
 'DBUS_SESSION_BUS_ADDRESS',
 'DEFAULTS_PATH',
 'DESKTOP_SESSION',
 'DISPLAY',
 'GPG_AGENT_INFO',
 'GS_LIB',
 'GTK2_RC_FILES',
 'GTK_CSD',
 'GTK_MODULES',
 'GTK_RC_FILES',
 'HOME',
 'INCLUDE',
 'KDE_FULL_SESSION',
 'KDE_SESSION_UID',
 'KDE_SESSION_VERSION',
 'KONSOLE_DBUS_SERVICE',
 'KONSOLE_DBUS_SESSION',
 'KONSOLE_PROFILE_NAME',
 'LANG',
 'LANGUAGE',
 'LC_ADDRESS',
 'LC_IDENTIFICATION',
 'LC_MEASUREMENT',
 'LC_MONETARY',
 'LC_NAME',
 'LC_NUMERIC',
 'LC_PAPER',
 'LC_TELEPHONE',
 'LC_TIME',
 'LD_PRELOAD',
 'LESSCLOSE',
 'LESSOPEN',
 'LOGNAME',
 'LS_COLORS',
 'MANDATORY_PATH',
 'PAM_KWALLET5_LOGIN',
 'PAM_KWALLET_LOGIN',
 'PATH',
 'PROFILEHOME',
 'PWD',
 'QT_ACCESSIBILITY',
 'QT_AUTO_SCREEN_SCALE_FACTOR',
 'SESSION_MANAGER',
 'SHELL',
 'SHELL_SESSION_ID',
 'SHLVL',
 'SSH_AGENT_PID',
 'SSH_AUTH_SOCK',
 'TERM',
 'USER',
 'WATCOM',
 'WINDOWID',
 'XAUTHORITY',
 'XCURSOR_THEME',
 'XDG_CONFIG_DIRS',
 'XDG_CURRENT_DESKTOP',
 'XDG_DATA_DIRS',
 'XDG_RUNTIME_DIR',
 'XDG_SEAT',
 'XDG_SEAT_PATH',
 'XDG_SESSION_CLASS',
 'XDG_SESSION_DESKTOP',
 'XDG_SESSION_ID',
 'XDG_SESSION_PATH',
 'XDG_SESSION_TYPE',
 'XDG_VTNR',
 '_']

Anaconda ist eine Python-Distribution, die über das `conda`-Programm viele Packages mit Modulen, die in C geschrieben sind und/oder von C-Bibliotheken abhängig sind, inklusive dieser Abhängigkeiten, installierbar macht. Das ist unter Windows nützlich weil man sonst Probleme mit solchen Packages bekommen kann, weil Windowsbenutzer das nicht gewohnt sind, dass man Bibliotheken installieren und C-Quelltexte compilieren muss. Viele Windowsbenutzer haben auch die nötige Infrastruktue (C-Compiler, …) gar nicht installiert.

Es gibt zwar immer mehr Packages im Package-Index die auch WHL-Dateien für Windows mit vorkompilierten Bibliotheken und Abhängigkeiten für verschiedene Python-Versionen haben, aber es sind noch nicht alle.

Das ist übrigens auch ein Grund warum ich persönlich gerne mindestens eine Python-Version hinterher hänge: Die Wahrscheinlichkeit, dass es was vorkompiliertes im Package-Index gibt, ist da einfach höher.

[Findus.]

vielen Dank das hat sehr geholfen.