Python - Immer noch ein Standard?

[Gast]

Bei mir an der Uni kommt neben MATLAB überwiegend Python zum Einsatz. Vor allem im Bereich CFD, Fluid-Modellierung und Matrizen / Vektorisieren.

Das letzte mal, als ich mit Python gecodet habe, muss im Info LK während des Abis gewesen sein.

Ist Python immer noch ein gewichtiger Standard?

Ist Python mächtig im Sinne der Möglichkeiten bzw. des Umfangs? Lässt sich damit fast alles bewerkstelligen?

Ist es eine "leichte" Programmiersprache?

[sven2.0]

ja
ja
ja

[patermatrix]

ja
ja
ja

+1

Hat insbesondere durch den ganzen ML Bereich nochmals einen gewaltigen Schub erhalten.

[Asaraki]

Ich finde Python sehr leicht, aber es war auch erst meine 5 Sprache oder so. Ist halt wie überall, wenn du die Vergangenheit kennst macht die Gegenwart deutlich mehr Sinn ^^

Aber ja, Python ist top

[Gast]

Ja, ist halt bloß das hier bzw. man sollte sehr schnell aufpassen, was man machen muss, wenn man Python-Kram distributen will: https://xkcd.com/1987/

[pest]

Python ist eine Skriptsprache
man sollte nicht anfangen damit ernsthaftes OOP betreiben zu wollen - das bietet der Sprachstandard nicht
man kann Einiges "emulieren" aber es ist mehr "tun al ob" zB. "abstrakte Klassen"

für schnelles Prototyping und im Bereich ML ideal
sobald dein Programm komplexer wird bekommst du mit Python ernsthafte Probleme und von der Performance - abseits von importierten Libs - gar nicht zu reden

"jeder" kann heute Python - und 90% davon können dir nicht mal erklären wie die Übergabekonvention bei mutable/immutable types funktioniert

[Asaraki]

Pest, nur 90? Du bist verwöhnt ^^

[Shink]

für schnelles Prototyping und im Bereich ML ideal

Blöde Frage aber: Warum eigentlich? Es gib jüngere, ältere, einfachere und kompliziertere Sprachen.
Ich mag Python, hab es vor 20 Jahren gerne "zum Spaß" verwendet aber dachte nicht, dass das mal so durch die Decke geht wie in den letzten 10 Jahren.

[Exxtreme]

Weil Python sehr simpel ist und gleichzeitig eine recht einfache Möglichkeit bietet C-Bibliotheken einzubinden und gleichzeitig nicht an ein OS gebunden ist. Das können andere Sprachen nicht in dieser Kombination.

[Ganon]

Ich glaube das hat weniger was mit Python direkt zu tun. Ruby ist sogar noch einfacher und hat sonst änliche Eigenschaften wie Python.

Die ML-Community hat sich einfach um Python herum gebildet und diverse ML-Tools wurden eben vor zig Jahren für die Nutzung durch Python gebaut. Ist so ein Henne-Ei Ding.

[Gliese]

Außerdem ist Python fast überall schon da.
Ich finde, es ist eine perfekte Bash-Ergänzung, wenn man etwas mehr Logik in seinen Scripts hat.
So Konstrukte à la
for i in $( cat liste.txt | awk -F':' '{print ...}' ); do (cat $i | awk '{for ... print ...)' | sort -nr | sed ... | ... | for ... | ... | done | done
kann schon nach wenigen Wochen kein Mensch mehr verstehen, inklusive man selber. Bash nennt man nicht umsonst eine Write-Only-Sprache. :freak:
Dann lieber eine Sprache wie Python, wo man vernünftig ohne Verrenkungen mit Strings und Arrays hantieren kann.

[pest]

Man muss auch bedenken wie groß der Abstraktionsgrad bei ML mittlerweile in Python ist

ein RAG System um mittels ChatGPT auf deinen PDFs zu chatten?
20 Zeilen Code und dann deployst du das Ding mit einem Klick direkt auf Azure
das ist schon krass

ich habe auch Server-Backends in Python gesehen - das sind dann doch Schmerzen

aber mit Generatoren und Dekoratoren kann man schon ne Menge Unfug anstellen wo ich in C++ erstmal lange nachdenken müsste

[Ganon]

Außerdem ist Python fast überall schon da.

Also unter Linux ja, aber sonst wo?

[patermatrix]

Also unter Linux ja, aber sonst wo?
Unter MacOS gibts (noch) gratis Python 2 :whistle:

Finde den Punkt aber eh nicht so relevant, weil das Runtime-, Versions- und Dependencymanagement gemessen an der Verbreitung der Sprache nicht wirklich komfortabel ist. Ich wundere mich eher, dass Python so verbreitet ist, obwohl das Management von Sprache und Paketen so mühsam ist ;(

Python etablierte sich früh in der Mathematik-Welt, als Umgebung für Numerik, Simulationen, Statistik, Visualisierung und dergleichen. Bibliotheken wie NumPy, SciPy, Mathplothlib etc. gibt es so umfangreich und so gratis zugänglich mMn nirgends sonst. ML kam als Anwendungsbereich dazu (z.B. Tensorflow), weil die Basis bereits so etabliert war.

Kann gut sein, dass die von Exxtreme erwähnten C-Bibliotheken dafür auch eine grosse Rolle spielten.

Weil Python [...] eine recht einfache Möglichkeit bietet C-Bibliotheken einzubinden

[The_Invisible]

Python ist das neue Basic, in 99% der Fälle interessiert die Geschwindigkeit halt nicht bzw ist schnell genug.

Warum soll ich in C/C++ mich stundenlang herumärgern um ein File herunterzuladen und einzulesen und zu parsen wenn ich das in Python in ein paar Minuten und Zeilen kann.

Wenns was zu kotzen gibt dann nehmt lieber Electron & Co Apps her ;)

[Gast]

Unter MacOS gibts (noch) gratis Python 2 :whistle:

Finde den Punkt aber eh nicht so relevant, weil das Runtime-, Versions- und Dependencymanagement gemessen an der Verbreitung der Sprache nicht wirklich komfortabel ist. Ich wundere mich eher, dass Python so verbreitet ist, obwohl das Management von Sprache und Paketen so mühsam ist ;(

Python etablierte sich früh in der Mathematik-Welt, als Umgebung für Numerik, Simulationen, Statistik, Visualisierung und dergleichen. Bibliotheken wie NumPy, SciPy, Mathplothlib etc. gibt es so umfangreich und so gratis zugänglich mMn nirgends sonst. ML kam als Anwendungsbereich dazu (z.B. Tensorflow), weil die Basis bereits so etabliert war.

Kann gut sein, dass die von Exxtreme erwähnten C-Bibliotheken dafür auch eine grosse Rolle spielten.

Ist Matlab nicht eine bessere und modernere Alternative im wissenschaftlichen Bereich?

[pest]

Ist Matlab nicht eine bessere und modernere Alternative im wissenschaftlichen Bereich?

MATLAB ist proprietär und kostet richtig Asche
Mir tun Leute leid die damit arbeiten (müssen)

[Pinoccio]

Also unter Linux ja, aber sonst wo?In QGIS ist's quasi mit drin. (Um mal ein für mich relevantes Beispiel zu erwähnen.)MATLAB ist proprietär und kostet richtig Asche
Mir tun Leute leid die damit arbeiten (müssen)Für einige Dinge tut es dann auch Octave.
Wer die ausgefeilten Sachen in MATLAB braucht, der müste jede Alternative auch teuer bezahlen.

mfg

[Actionhank]

MATLAB ist proprietär und kostet richtig Asche
Mir tun Leute leid die damit arbeiten (müssen)
Wegen des Geldes?
Hat alles Vor- und Nachteile.

[Holundermann]

Man muss auch bedenken wie groß der Abstraktionsgrad bei ML mittlerweile in Python ist

ein RAG System um mittels ChatGPT auf deinen PDFs zu chatten?
20 Zeilen Code und dann deployst du das Ding mit einem Klick direkt auf Azure
das ist schon krass

ich habe auch Server-Backends in Python gesehen - das sind dann doch Schmerzen

aber mit Generatoren und Dekoratoren kann man schon ne Menge Unfug anstellen wo ich in C++ erstmal lange nachdenken müsste

Ich arbeit im Strassentelemtry bereich. Wir verwenden im backend ausschließlich python3 -ich kann mich nicht über fehlende performance beschweren. Der bottleneck ist ohnehin immer die Datenbank und Python3 ist zwar eine skript sprache - die libraries verwenden dann aber doch oft die darunterliegende C library. Ausserdem wird python code bei der ausführung quasi kombiliert.

Nachteile hat python3 eigentlich nur beim multithreading wegen den global interpreter lock. Ansonsten ist die Infrasturktur (= verfügbare libararies und 3rd party support) einfach top.

Was am deployment schwierig sein soll erschliest sich mir nicht - es lassen sich kinderleicht services schreiben (systemd) und ausführen, man kann auch seine eigenen bibliotheken bundeln und es gibt ja die venvs um für die jeweiligen projekte die richtige python version bzw. die richtigen libraries verwenden zu können. Ausserdem läuft heute eh alles in docker containern...

[pest]

Wegen des Geldes?


Da kann ich mir keine Meinung erlauben, da ich MATLAB zu wenig verwendet habe
Ich denke für Numerik POCs super

da ich in Python oft das Problem hatte, dass Sachen vom Reisbrett in Python manchmal suboptimal von der Performance waren,
da bestimmte Codepfade direkt an C-Libs angebunden waren, andere nicht, obwohl es absolut unlogisch war

Zusätzlich die ganzen Probleme die aus "non strongly typed" entstehen.
Da liefert eine Funktion eine dense-matrix zurück und man sollte aus Performance gründen aber eine Sparse-matrix nehmen.
Das bekommt man aber gar nicht mit, da man "alles in alles" stecken kann.

Großes Problem sind auch (unbeabsichtigte) Nebenläufigkeiten die viele nicht auf dem Schirm haben

Der bottleneck ist ohnehin immer die Datenbank und Python3 ist zwar eine skript sprache

wenn das so ist, ist ja gut
als webframework ist fast-api ca 3-4x mal langsamer als .net core
https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22

ist auch meine Erfahrung - dass .net core einfach mehr load aushält bevor es horizontal skalieren muss


die libraries verwenden dann aber doch oft die darunterliegende C library.


Richtig - effizientes Python ist die Kunst Library-Calls aneinanderzukleben


Ausserdem wird python code bei der ausführung quasi kombiliert.


nein, Python hat kein JIT. Es gibt verschiedene Libs die das bereitstellen, zB Numba

Was am deployment schwierig sein soll erschliest sich mir nicht

Hab nix dazu geschrieben

[Ganon]

Was am deployment schwierig sein soll erschliest sich mir nicht

Es wird halt eklig, wenn man das Zielsystem nicht in der Hand hat. Versuche mal Python 3.11 samt aller deiner Abhängigkeiten inkl. der benötigten C-Bibliotheken auf einem RHEL7 Linux zu installieren, der nicht am Internet hängt.

Viel Spaß! Und zumindest in meinem Umfeld werden Dinge wie Docker bzw. Container allgemein noch abgelehnt.

Alles ist schön, wenn pip die entsprechenden Sachen für das Zielsystem (Python Version X Library Version X OS Version) da hat. Der Abgrund tut sich auf, wenn das nicht der Fall ist und das System anfängt diese ganzen "schönen" C-Libraries auf deinem System zu kompilieren.

[pest]

Und zumindest in meinem Umfeld werden Dinge wie Docker bzw. Container allgemein noch abgelehnt.


https://user-images.githubusercontent.com/2131310/198965478-5dffe734-856b-4253-8f48-bcc6f5c9ed63.png

[Holundermann]

Zusätzlich die ganzen Probleme die aus "non strongly typed" entstehen.
Da liefert eine Funktion eine dense-matrix zurück und man sollte aus Performance gründen aber eine Sparse-matrix nehmen.
Das bekommt man aber gar nicht mit, da man "alles in alles" stecken kann.


Das hat mich anfangs auch massiv gestört. Jedoch gibt es seit python3 die möglichkeit parameter zu typen - all unser produktivcode verwendet typing.


Großes Problem sind auch (unbeabsichtigte) Nebenläufigkeiten die viele nicht auf dem Schirm haben


Weiss nicht was du damit meinst - ich habe keine unbeabsichtigten Nebenläufigkeiten. Hab schon alles verwendet von Threading/Processing und asyncio. Alles geht und hat seine vor und Nachteile. Es gelten die selben Regeln wie in anderen Programmiersprachen (Events/Locks/...)



wenn das so ist, ist ja gut
als webframework ist fast-api ca 3-4x mal langsamer als .net core
https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22

ist auch meine Erfahrung - dass .net core einfach mehr load aushält bevor es horizontal skalieren muss


Das will ich gar nicht abstreiten das natürlich andere Programmiersprachen schneller sind. Jedoch ist für unseren Zweck python3 schnell genug. Ich arbeite viel mit FastAPI - ist das schönste Stück Software welches ich je verwenden durfte. Es ist kinderleicht eine API zu erstellen und die OpenAPI spezfikation wird gleich mit generiert.


Richtig - effizientes Python ist die Kunst Library-Calls aneinanderzukleben


Man kann auch selbst c/c++ code schreiben und diesen dann über eine python library bereitstellen. Haben wir bisher noch nicht benötigt aber es geht.


nein, Python hat kein JIT. Es gibt verschiedene Libs die das bereitstellen, zB Numba


Das ist evtl. definitionssache. Fakt ist das CPython - die Standard Implementierung von Python - pyc files erzeug (=bytecode) - siehe dazu auch die hervorragende Erklärung auf Stack Overflow: https://stackoverflow.com/questions/2998215/if-python-is-interpreted-what-are-pyc-files


Es wird halt eklig, wenn man das Zielsystem nicht in der Hand hat. Versuche mal Python 3.11 samt aller deiner Abhängigkeiten inkl. der benötigten C-Bibliotheken auf einem RHEL7 Linux zu installieren, der nicht am Internet hängt.


Ich hab sowas ähnliches vor kurzem gemacht. Jedoch weiterhin Python 3.6 vom OS verwendet und nicht noch den Interpreter gebundeld mit meinem RPM package. Alle libraries hab ich jedoch mit deployt - aber den python interpreter mitdeployen wäre sicher spannend auf so einem alten System :) - evtl. 3rd party repos einbinden um an neuere interpreter versionen zu kommen?

Wer heutzutage nicht mit containern deployt ist selber schuld. Es braucht zwar ein wenig einarbeitung aber es löst soviele Probleme! Kann ich nur empfehlen. Verwende auch viel container wärend der Entwicklung - um etwa unittests gegen eine echte DB zu machen.

[Ganon]

Ich hab sowas ähnliches vor kurzem gemacht. Jedoch weiterhin Python 3.6 vom OS verwendet und nicht noch den Interpreter gebundeld mit meinem RPM package. Alle libraries hab ich jedoch mit deployt - aber den python interpreter mitdeployen wäre sicher spannend auf so einem alten System :) - evtl. 3rd party repos einbinden um an neuere interpreter versionen zu kommen?

Und Zeug aus einem 3rd Party Repo installierst du wie ohne Internet? :D Aber klar, es ist schon irgendwo möglich, aber es ist halt verdammt umständlich. Am Ende habe ich mir das RHEL bzw. CentOS7 in einer VM installiert und das Paket für den Kunden fertig gebaut.

Wer heutzutage nicht mit containern deployt ist selber schuld.

Sagt das der IT von meinen Kunden. Wie ich ja schon sagte, wenn man das Zielsystem quasi in der Hand hat, ist das alles ganz einfach. Abseits davon wird es sehr unschön.

Sehr spannend sind übrigens auch Deployments in China. Das Internet hinter der "Great Firewall" ist schon was eigenes. Dort hat man am besten auch alles für das Zielsystem vorab parat, ansonsten darfst du dir erst mal einen chinesischen Mirror suchen, der den Kram hat.

[Gast]

MATLAB ist proprietär und kostet richtig Asche
Mir tun Leute leid die damit arbeiten (müssen)

Ich arbeite damit umsonst. Neuste Version.

Und auch die Home Version ist jetzt nicht sooo teuer. 119€

https://de.mathworks.com/products/matlab-home.html

[Pinoccio]

Ich arbeite damit umsonst. Neuste Version.

Und auch die Home Version ist jetzt nicht sooo teuer. 119€

https://de.mathworks.com/products/matlab-home.html"Arbeiten" und "Home Version" schließt sich für die meisten halt aus ...

mfg

[The_Invisible]

Sagt das der IT von meinen Kunden. Wie ich ja schon sagte, wenn man das Zielsystem quasi in der Hand hat, ist das alles ganz einfach. Abseits davon wird es sehr unschön.


Hört sich nach einem typischen Konzern an der so beweglich ist wie ein Berg.

Haben wir auch, einfach Deployment/Supportkosten nach oben schrauben, manchmal wird dann doch (ein wenig) eingelenkt.

[Ganon]

Hört sich nach einem typischen Konzern an der so beweglich ist wie ein Berg.
Haben wir auch, einfach Deployment/Supportkosten nach oben schrauben, manchmal wird dann doch (ein wenig) eingelenkt.

Ja, typische Konzerne eben :D Aber klar, kostenlos wird der ganze Kram nicht gemacht. Aber bisher sind alle bereit den Kram zu bezahlen, statt sich selbst zu bewegen.

[Marscel]

Ach Leute, Python ist doch ganz einfach zu managen:

1. Man installiert git.
2. Dann installiert man pyenv von GitHub, und wenn man da neue Versionen installieren will, muss man mit git ein Update ziehen.
3. Dann installiert man pyenvs Shell-Handler
4. Dann packt man in das Projekt eine .pyenv-Datei, die die Python-Version fest zieht
5. Dann lässt man pyenv Python installieren
6. Dann upgradet man pip für das geladene Python
7. Dann installiert man mit pip pipx für das geladene Python, wenn man Python-Tools für Python braucht (sowas wie flake8) -- ja, das hat seinen Grund besser so zu tun
8. Dann installiert man mit pipx virtualenv
9. Dann startet man virtualenv für das Projekt mit pipx
10. Dann installiert man mit dem aus pipx gevirtuelenvten pip aus dem gittigen gepyenvten Python die requirements.txt
11. Fertig ist die Box.

Kriegt der Standardnutzer easy hin. Und auch für Docker eine kleine Pro-Anleitung fürs reproduzierbare Builds mit Thrill-Factor:

1. Alpine-Image weil geil, klein, irgendwie so.
2. Eine Compiler-Chain und Libraries installieren.
3. Wenn es nicht die gewünschte Python Version bei apk gibt, dann Schritte 1 bis 10 machen, sicher ist sicher.
4. 45 Minuten dabei warten, weil irgendwo numpy, Pandas oder Arrow drin steckt, und weil die C-Library hiermusl heißt und nicht glibc, müssen nun alle precompiled C-Libs von pypi.org discarded und neukompiliert werden müssen und phasenweise mit einem ganzen Thread alles gemacht wird.
5. Einen Fehler wg. fehlender Library-Header feststellen, die in apk heraussuchen, und wieder bei 2. anfangen.
6. Ein neues Docker-Image anlegen, und mittels FROM aus den Python-Verzeichnissen aus dem alten Image die ganzen nun heruntergeladenen und kompilierten Python-Sache rüberzukopieren. So halten wir die 800MB Build Chain gcc & Co aus dem neuen Image fern.
7. Den Anwendungscode rüberkopieren.
8. Fertig ist unser 20MB Python Docker Image nun.

[Gast]

Ach Leute, Python ist doch ganz einfach zu managen:

1. Man installiert git.
2. Dann installiert man pyenv von GitHub, und wenn man da neue Versionen installieren will, muss man mit git ein Update ziehen.
3. Dann installiert man pyenvs Shell-Handler
4. Dann packt man in das Projekt eine .pyenv-Datei, die die Python-Version fest zieht
5. Dann lässt man pyenv Python installieren
6. Dann upgradet man pip für das geladene Python
7. Dann installiert man mit pip pipx für das geladene Python, wenn man Python-Tools für Python braucht (sowas wie flake8) -- ja, das hat seinen Grund besser so zu tun
8. Dann installiert man mit pipx virtualenv
9. Dann startet man virtualenv für das Projekt mit pipx
10. Dann installiert man mit dem aus pipx gevirtuelenvten pip aus dem gittigen gepyenvten Python die requirements.txt
11. Fertig ist die Box.

Kriegt der Standardnutzer easy hin. Und auch für Docker eine kleine Pro-Anleitung fürs reproduzierbare Builds mit Thrill-Factor:

1. Alpine-Image weil geil, klein, irgendwie so.
2. Eine Compiler-Chain und Libraries installieren.
3. Wenn es nicht die gewünschte Python Version bei apk gibt, dann Schritte 1 bis 10 machen, sicher ist sicher.
4. 45 Minuten dabei warten, weil irgendwo numpy, Pandas oder Arrow drin steckt, und weil die C-Library hiermusl heißt und nicht glibc, müssen nun alle precompiled C-Libs von pypi.org discarded und neukompiliert werden müssen und phasenweise mit einem ganzen Thread alles gemacht wird.
5. Einen Fehler wg. fehlender Library-Header feststellen, die in apk heraussuchen, und wieder bei 2. anfangen.
6. Ein neues Docker-Image anlegen, und mittels FROM aus den Python-Verzeichnissen aus dem alten Image die ganzen nun heruntergeladenen und kompilierten Python-Sache rüberzukopieren. So halten wir die 800MB Build Chain gcc & Co aus dem neuen Image fern.
7. Den Anwendungscode rüberkopieren.
8. Fertig ist unser 20MB Python Docker Image nun.

Das hört sich ja wie Linux-Gefrickel an....

[Gast_2]

In der Forschung/Wissenschaft und Entwicklung ist Python weiterhin ungebremst auf dem Vormarsch. Bei uns wird nahezu alles in Python gemacht, Datenanalyse/-auswertung findet praktisch überall nur noch in Python statt. Auch für ganz aktuelle Entwicklungen hinsichtlich KI, Deep Learning und co. sind die relevanten und am aktivsten von der Wissenschafts-Community weiterentwickelten Bibliotheken in Python geschrieben. Wer kein Python machen will, braucht in vielen Fällen in Bereich gar nicht erst anzufangen.

[ENKORE]

Es wird halt eklig, wenn man das Zielsystem nicht in der Hand hat. Versuche mal Python 3.11 samt aller deiner Abhängigkeiten inkl. der benötigten C-Bibliotheken auf einem RHEL7 Linux zu installieren, der nicht am Internet hängt.

Viel Spaß! Und zumindest in meinem Umfeld werden Dinge wie Docker bzw. Container allgemein noch abgelehnt.

Alles ist schön, wenn pip die entsprechenden Sachen für das Zielsystem (Python Version X Library Version X OS Version) da hat. Der Abgrund tut sich auf, wenn das nicht der Fall ist und das System anfängt diese ganzen "schönen" C-Libraries auf deinem System zu kompilieren.

Wie genau ist Binärkompatibilität ein Python-spezifisches Problem?
Also abgesehen von dem Teil, wo Python über die manylinux-ABIs und -Buildcontainer eine der robusteren Lösungen in dem Bereich hat.

[Ganon]

Wie genau ist Binärkompatibilität ein Python-spezifisches Problem?

Ist natürlich kein Python-spezifisches Problem. Aber es würde auch niemand behaupten, dass C/C++ Deployments "einfach" wären.