Ist Python 3.12 abwärts kompatibel zu 3.11 und 3.10

[alfware17]

Hallo ich richte gerade ein paar neue PC bzw Virtualboxen ein und alle sollen ein Python und eine IDE bekommen.

Unter Linux ist die Wahl leicht - ich nehme einfach das Python was da ist, bei Linux Mint bei mir zB 3.9 und 3.10 was ich völlig ok und ausreichend für mich als Anfänger finde. Als IDE funktioniert Visual Studio Code 1.76 bzw nach Update 1.93

Bei Windows ist die Sache schon verzwickter. Ich "brauche" teils noch Win 7, also nehme ich Python 3.8.8 und Visual Studio 1.76, PyCharm hatte ich auch schon am Laufen.#

Für Win 10 bzw perspektivisch 11 habe ich mir Python 3.10.11, Python 3.11.9 und Python 3.12.4 installiert - als Laie sehe ich da keine Unterschiede. Oder doch? Was meint Ihr, sollte ich nehmen. Mit 3.10 möglichst lange nach unten offen bleiben? Oder gleich zu 3.12 gehen und dann aber riskieren, daß mir ein paar Sprachelemente "depricated" angemeckert werden und ich einige Programme nicht mehr in allen Systemen laufen lassen kann?

Als IDE wollte ich Visual Studio Code 1.9.2 nehmen und dazu PyCharm 2024 die neue. Laufen tut von meinen Beispielen alles, wenn ich mal davon absehe, daß ich zwar reine Python-Programme aber nur sehr eingeschränkt Jupyter Notebooks benutzen kann, mit denen stehe ich irgendwie auf Kriegsfuß.

Wie macht ihr das, gibt es Empfehlungen bzw "best practice"? Vor allem zur Frage welches Python man denn nun nehmen soll?

[sparrow]

3.8 ist 5 Jahre alt und fällt nächsten Monat aus dem Support.
Ich kenne keinen vertretbaren Grund die Version (oder Windows 7, das schon seit 2020 nicht mehr supported wird) einzusetzen.

3.12 ist inzwischen ein Jahr released und die wichtigsten Bibliotheken sollten darauf umgestellt haben.

[alfware17]

Danke für deine Antwort, die meine Frage jedoch nicht beantwortet. Ich habe halt eine heterogene Systemlandschaft und möchte gerne Anwendungen entwickeln, die auf möglichst vielen Computern ohne oder mit geringen Anpassungen laufen und den Nutzern Freude bringen. Ich dachte, daß wäre jetzt auch der Sinn bzw die Kunst in der Informatik. Mit den heutigen Release- und Wegschmeißzyklen würde ein Raumschiff sicher niemals auf den Mars oder auch nur aus der Garage kommen.

Ich verstehe die Aussage nicht: Level x.y einer Programmiersprache oder eines Betriebssystems ist "aus dem Support" seit 5 Jahren oder 3 Monaten - also liebe Leute kauft alle nur nur noch das neue und das ist dann in 3 Jahren auch wieder kaputt.Wollen Informatiker denn gar nicht mehr basteln heutzutage?

[__blackjack__]

@alfware17: Diese Aussagen haben als Hintergrund, dass alte, nicht mehr unterstützte Software nicht selten die Sicherheitslücken ist, die Viren, Trojaner, Kriminelle, … ausnutzen. Ich weiss auch nicht was das mit basteln wollen zu tun hat. Man will sich halt nicht unnötig einen ganzen Zoo an Versionen ans Bein binden den man dann unterstützen muss, und da Zeit investieren, die man auch auf das entwickeln/basteln des eigentlichen Programms stecken kann.

Für den tatsächlichen Einsatz verwende ich persönlich maximal die vorletzte Python-Version, weil da (hauptsächlich wegen Windows) dann schon alle wichtigen Bibliotheken von Drittanbietern mit C-Anteilen als Wheels installiert werden können. Es macht aber Sinn auch die neueste Version zu installieren, wenn man schauen will, ob ein Umstieg darauf Änderungen am eigenen Code erfordert.

Python ist in der Regel recht rückwärtskompatibel. Ausnahme: der Schritt von 2.x auf 3.x.

Was das kaufen angeht: Python ist kostenlos. Das Betriebssystem muss auch kein Geld kosten.

[OketraSuperpower]

Du könntest aber auch deine Python Skripte mit Unittests versehen (soweit das möglich ist) und diese dann z.B. in einem CI / CD Workflow mit verschiedenen Python Versionen laufen lassen (hier z.B. für GitHub Actions https://docs.github.com/de/actions/use- ... n-versions).

[alfware17]

Okay ich wollte und will keine Systemdiskussion beginnen.
Darum noch mal meine Frage so einfach und neutral wie möglich: Gibt es Gründe, weshalb ich - Stand heute - bei Neueinrichtung lieber Python 3.12 oder 3.11 oder 3.10 nehmen sollte? Sprich gibt es Funktionen oder Sprachfeatures, die man unbedingt haben soll (ich sehe als Anfänger auf Anhieb nichts). Oder ist durch etwas der Unterschied zu Computern, die ich noch mit Python 3.8 bzw 3.9 betreiben MUSS (nicht will) zu groß?
Es geht um Neueinrichtung. Daß ich noch 1-2 PC habe, an denen ich gerne sitze und wo ich auch mit Python begonnen habe, hätte ich vielleicht nicht schreiben sollen.
Ja der Sprung von Python 2.7 auf Python 3.79 war damals heftig, auch weil die Lehre/der Kurs immer von dem abwich, was man zuhause machen konnte. Gestern habe ich dem 3.79 -> 3.88 verpaßt und siehe da, ich konnte sogar das mit Jupyter Notebook (aus einem anderen Thread) dort nachvollziehen.
Zwischen 3.10 und 3.12 sehe ich keinen Unterschied, daher frage ich. Ich hätte mich auch auf 3.9x festlegen können, dachte mir nur wenn ich nun schon mal neu einrichte, soll es auch 4-5 Jahre reichen

[noisefloor]

Wenn du selber keinen Grund kennst, Python Version $FOO zu nehmen -> nimm' die, die deine Linux Distro OOTB an Bord hat und für Windows die aktuellste, stabile, die du aus dem Microsoft Store installieren kannst. Das Python im MS Store wird direkt von der Python Software Foundation bereit gestellt und über das MS Store bekommst du auch automatisch Sicherheitsupdates für den jeweiligen Python-Release.

Gruß, noisefloor

[grubenfox]

Wobei sich IMHO speziell bei Linux empfiehlt folgendes zu beachten:

In der Regel richtet man sich halt pro Projekt ein lokales virtual environment an, installiert da per pip seine Pakete rein und das war's dann schon.

Bei Windows bin ich recht zuversichtlich dass das auch noch mit einer kaputt gemachten Python-Installation funktioniert. Während ich bei Linux den Eindruck habe dass die Python Version die von der Linux Distro OOTB mitgeliefert wird auch für einen größeren Teil des Linux-Systems genutzt wird.

Wenn man sich dann, durch einfaches Installieren aller möglichen und nötigen Pakete für diverse eigene Projekte in dieses System-Python, eben dieses System-Python zerschossen hat, dann weiß ich nicht was dann vom Linux-System noch korrekt läuft.
Außerdem wird bei dem System-Python (was durch den jeweiligen Linux-Paketmanager installiert wurde) vermutlich auch pip meckern weil man nicht parallel Pakete mit pip auf der einen Seite und dem Linux-Paketmanager auf der anderen Seite installieren sollte.

[noisefloor]

Während ich bei Linux den Eindruck habe dass die Python Version die von der Linux Distro OOTB mitgeliefert wird auch für einen größeren Teil des Linux-Systems genutzt wird.

Korrekt, AFAIK ist in den allermeisten Linuxdistros (sicher bei Debian, Ubuntu und allem, was darauf baut) Python integraler Teil der Installation und wird vom System benötigt, weswegen man _tunlichst_ darauf verzichten sollte, das systemweite Python zu ersetzen. Parallelinstallation ist natürlich möglich, oder man benutzt sowas wie pyenv. Des Weiteren sollte man tunlichst darauf achten, systemweit installierte Python-Module nicht durch manuell installierte zu ersetzen. Die neueren Version von pip unterbinden das auch erstmal - kann man aber natürlich übersteuern, wenn man möchte.

Windows braucht kein Python. Nichts desto trotz sollte man auch hier keine wilden Installationsorgien abhalten und venv nutzen.

Gruß, noisefloor

[alfware17]

Wie jetzt, "Windows braucht kein Python"? Wie soll man denn sonst programmieren?

Also unter Linux das vorinstallierte zu nehmen, finde auch ich eine gute Idee. Schon alleine deswegen weil es größerer Klimmzüge bedarf das vorinstallierte dann zu ersetzen. Und wenn die Unterschiede 3.xy eh nicht so groß sind?
Daß ich aus dem Windows-Store auch ein aktuelles Python bekomme, halte ich erstmal für ein Gerücht: im Selbstversuch lehnte der "Microsoft Store" sowieso erstmal jegliche weitere Zusammenarbeit und Installation ab, bevor ich nicht zwangsweise auf Win11 update. Aber ok - Python 3.10-3.12 funktionieren bei mir scheinbar gleichwertig, also nehme ich das 3.11 und gut ist. Ich hatte mir nur gemerkt - bei Python (ja Java auch usw) sollte man möglichst nicht die Version so oft ändern und da wollte ich eben möglichst lange auf der sicheren Seite sein

[pillmuncher]

Wie jetzt, "Windows braucht kein Python"?

Unter Linux gibt es einige System-Utilities, die in Python programmiert sind. Das installierte Python ist für die notwendig. Unter Windows ist das nicht der Fall. Anders ausgedrückt: Windows braucht kein Python.

Also unter Linux das vorinstallierte zu nehmen, finde auch ich eine gute Idee. Schon alleine deswegen weil es größerer Klimmzüge bedarf das vorinstallierte dann zu ersetzen.

Was passiert, wenn du für ein Projekt von pypi.org eine neuere Version eines Paket in dein System-Python installierst, die mit irgendeinem installierten System-Utility nicht kompatibel ist? Richtig, du hast dein System verborkt. Unter Windows mag das ein vernachlässigbares Problem sein, aber was passiert, wenn du selber verschiedene Projekte hast, und die brauchen zufällig unterschiedliche Versionen desselben Pakets? Etwa, weil du das erste vor einem Jahr programmiert hast, und das nächste gerade eben? Willst du dann das alte Programm and die neue Paket-Verison anpassen müssen? Was, wenn es nicht ein altes Programm ist, sondern zehn?

[alfware17]

Im Verbocken von Linux-Systemen bin ich großartig.... Kleine Auswahl gefällig?
- hab mal im Linux GPG 1 deinstalliert, weil ich dachte habe ja noch GPG 2 jetzt neu... gleicher Effekt wie beim Python, Linux braucht es eben
- habe Java aus einer Drittquelle installiert, anschließend funktionierten keine apt updates mehr und die Installation von Lazarus hat mir gtk20 und selbst Cinnamon komplett zerschossen - zum Glück sind die meisten meiner Linuxe virtuell
- auch mit Android Studio habe ich das genauso geschafft - Updates befolgt und nichts ging mehr
- selbst den Sprung von Linux Mint 21.1 auf 21.3 den ich nur aus kosmetischen Gründen machte und weil ich auch mal aktuell sein wollte, bezahlte ich mit kompletten Systemcrash und Neuinstallation
Ich gebe zu, der Stunt mit dem Java+Lazarus war einmalig selbst für mich Hartgesottenen

Frage: Python 3.10.12 bzw 15 bringen keine eigenen Installer mehr mit. Wie komme ich dann von 3.10.11 auf 3.10.12? Ich vermute mal, Python kann das selbst updaten (pip?) aber wie? Habe jetzt lange gesucht und gelesen, diese anscheinend selbstverständliche Information erschließt sich mir nicht

[grubenfox]

No installers

According to the release calendar specified in PEP 619, Python 3.10 is now in the "security fixes only" stage of its life cycle: 3.10 branch only accepts security fixes and releases of those are made irregularly in source-only form until October 2026. Python 3.10 isn't receiving regular bug fixes anymore, and binary installers are no longer provided for it. Python 3.10.11 was the last full bugfix release of Python 3.10 with binary installers.

(aus https://www.python.org/downloads/release/python-31015/)

Also Sourcen von 3.10.15 runterladen und selbst übersetzen... (kann ich aber gar nichts zu sagen, habe ich nach meiner Erinnerung noch nie gemacht)

Ich habe da noch einen gefunden:
https://docs.python.org/release/3.10.15 ... in-3-10-15

[pillmuncher]

Im Verbocken von Linux-Systemen bin ich großartig
…
Frage: Python 3.10.12 bzw 15 bringen keine eigenen Installer mehr mit. Wie komme ich dann von 3.10.11 auf 3.10.12? Ich vermute mal, Python kann das selbst updaten (pip?) aber wie? Habe jetzt lange gesucht und gelesen, diese anscheinend selbstverständliche Information erschließt sich mir nicht

Nimm einfach eine aktuelle Python-Version, dann hast du solche Probleme nicht.

"If you don't write code like this, you don't have to worry about these sorts of questions." -- Steve Oualline.

[noisefloor]

Die manuelle Installation von Python unter Linux ist ziemlich simpel. Funktioniert auf Debian- / Ubuntu-basierten Systemen so: https://wiki.ubuntuusers.de/Python/manu ... tallation/

Wenn man gut im Zerschießen von Systemen ist: die 1. Kasten mit dem "Achtung!" lesen, nochmal lesen, verstehen, nochmal lesen und umsetzen.

Wem das zu kompliziert ist: Windows nehmen und Python aus dem Microsoft Store installieren.

Gruß, noisefloor

[narpfel]

Oder einfach Deadsnakes benutzen, dann hat man nicht das Problem, dass man sich aus Versehen ein kaputtes Python kompiliert, weil z. B. die OpenSSL-Header fehlen oder so ein Spaß.

[alfware17]

Die manuelle Installation von Python unter Linux ist ziemlich simpel. Funktioniert auf Debian- / Ubuntu-basierten Systemen so: https://wiki.ubuntuusers.de/Python/manu ... tallation/

Wenn man gut im Zerschießen von Systemen ist: die 1. Kasten mit dem "Achtung!" lesen, nochmal lesen, verstehen, nochmal lesen und umsetzen.

Wem das zu kompliziert ist: Windows nehmen und Python aus dem Microsoft Store installieren.

Gruß, noisefloor

Naja, das sagt sich aus deiner Sicht so leicht - bei genauerer Prüfung...
Im Windows habe ich alle Tips umgesetzt bekommen und es läuft alles soweit. Nur habe ich eben die Python-Installationen von python.org genommen und wenn es überhaupt etwas zu meckern gäbe dann das voreingestellte X bei den Administratorrechten. Den Microsoft Store kann ich NICHT nutzen, das hat der mir gerade schwarz auf weiß als Fehlermeldung gesagt, ich bin aber nicht traurig.

Zur Installation von Python in Linux habe ich mich am WE versucht, Ergebnis PyCharm und VS Code laufen mehr schlecht als recht, allerdings nur für einfache Python-Programme nicht für Jupyter. Sei's auch hier drum,
ich bin nicht traurig, mich nervt das alles nur noch. Wenn das voreinstellte Python kein tkinter und nicht einmal pip hat, wenn das .venv Einstellen anscheinend wieder an Rechteproblemen und notorischer Kleinschreibung scheitert oder das Python "python3" heißen muß, dann macht man sich damit Probleme wo eigentlich keine sein sollten. Ich habe dieses Jahr schon viele "einfache" manuelle Installationen von Java, Lazarus usw. geschafft und auch wenn ich jetzt hier bei Python aufgebe. Einfach und einsichtig war das alles nicht - sondern Kleinkram und Probleme und Sprödigkeit an Stellen, wo man es eigentlich nicht (mehr?) erwarten sollte, wenn das alles so selbstverständlich und automatisch ist.

[DeaD_EyE]

Der neuste heiße scheiß: uv

Ich habe noch nie so schnell Python-Interpreter installiert bzw. Pakete installiert:

uv findet sogar via pyenv installierte Python-Interpreter.
Ein weiterer Vorteil ist, dass man Python nicht kompilieren muss, d.h. auf der Maschine benötigt man weniger Abhängigkeiten, um Python zu installieren.

Code: Alles auswählen

public@ganymed:~$ uv python install 3.12.6
Searching for Python versions matching: Python 3.12.6
Installed Python 3.12.6 in 1.39s
 + cpython-3.12.6-linux-x86_64-gnu
public@ganymed:~$ uv venv
Using Python 3.12.6
Creating virtualenv at: .venv
Activate with: source .venv/bin/activate
public@ganymed:~$ source .venv/bin/activate
(public) public@ganymed:~$ uv pip install ipython ptpython matplotlib numpy scipy pysocks shed ruff black isort mypy pyserial
Resolved 46 packages in 769ms
Prepared 24 packages in 1.55s
Installed 46 packages in 70ms
 + appdirs==1.4.4
 + asttokens==2.4.1
 + black==24.8.0
 + click==8.1.7
 + com2ann==0.3.0
 + contourpy==1.3.0
 + cycler==0.12.1
 + decorator==5.1.1
 + executing==2.1.0
 + fonttools==4.53.1
 + ipython==8.27.0
 + isort==5.13.2
 + jedi==0.19.1
 + kiwisolver==1.4.7
 + libcst==1.4.0
 + matplotlib==3.9.2
 + matplotlib-inline==0.1.7
 + mypy==1.11.2
 + mypy-extensions==1.0.0
 + numpy==2.1.1
 + packaging==24.1
 + parso==0.8.4
 + pathspec==0.12.1
 + pexpect==4.9.0
 + pillow==10.4.0
 + platformdirs==4.3.3
 + prompt-toolkit==3.0.47
 + ptpython==3.0.29
 + ptyprocess==0.7.0
 + pure-eval==0.2.3
 + pygments==2.18.0
 + pyparsing==3.1.4
 + pyserial==3.5
 + pysocks==1.7.1
 + python-dateutil==2.9.0.post0
 + pyupgrade==3.17.0
 + pyyaml==6.0.2
 + ruff==0.6.5
 + scipy==1.14.1
 + shed==2024.3.1
 + six==1.16.0
 + stack-data==0.6.3
 + tokenize-rt==6.0.0
 + traitlets==5.14.3
 + typing-extensions==4.12.2
 + wcwidth==0.2.13
(public) public@ganymed:~$ python
7Python 3.12.6 (main, Sep  9 2024, 22:11:19) [Clang 18.1.8 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy
<module 'numpy' from '/home/public/.venv/lib/python3.12/site-packages/numpy/__init__.py'>
>>>

Das interessante ist, dass die Python-Interpreter mit clang kompiliert worden sind. Bei den mir bekannten Distributionen wird noch gcc verwendet.

[pillmuncher]

mich nervt das alles nur noch. Wenn das voreinstellte Python kein tkinter und nicht einmal pip hat, wenn das .venv Einstellen anscheinend wieder an Rechteproblemen und notorischer Kleinschreibung scheitert oder das Python "python3" heißen muß, dann macht man sich damit Probleme wo eigentlich keine sein sollten.

Dein Linux-Paketmanager installiert tkinter nicht, weil keines der Python-Programme, die der Paketmanager installiert hat, es braucht. Es zieht einen Rattenschwanz von anderem Kram mit sich, der dann ebenfalls installiert werden müsste, nämlich TCL/TK. Und weil man inzwischen Mechanismen wie virtuelle Umgebungen hat, braucht man das auch nicht.

pip wird die von deinem Linux-Paketmanager nicht zugänglich gemacht, damit du dir dein System nicht zerschießt. Du brauchst es auch nicht, weil es ja virtuelle Umgebungen und pyenv gibt.

Auch die Unterschiede zwischen Groß- und Klein-Schreibung haben nichts mit Python zu tun, sondern damit, dass Dateinamen in Linux case sensitive sind, in Windows aber nicht. Das Rechte-System von Linux ist auch anders, als auf Windows.

Und dass es beides, python3 und python gibt, liegt einfach daran, dass es - anders als unter Windows - Python-Programme gibt, die zum Linux-System gehören. Während des Übergangs von Python 2 zu Python 3 hat es ziemlich lang gedauert, bis alle diese System-Programme umgeschrieben wurden. Damit man beide Pythons - das für die alten Python 2 Programme und das für die angepassten Python 3 Programme - parallel verwenden konnte, musste man einen Unterschied machen. Unter Python 2 war der Programm-Name python und das musste so bleiben, weil die alten Programme einfach weiterlaufen sollten. Wenn dann ein Programm umgeschrieben wurde, wurde es auf python3 umgebogen. Du kannst gerne summarisch /usr/bin/python auf /usr/bin/python3 umbiegen, dann kannst du einfach python auf der Command Line verwenden. Du wirst dir aber damit womöglich dein System zerschießen, wenn es noch Programme in deinem Linux gibt, die die Version 2 erwarten. Your choice.

Dass es unter Linux mit Java solche Probleme kaum gibt, liegt einfach daran, dass unter Linux keine System-Programme in Java programmiert wurden. Das macht es dem Paketmanager einfach, weil Java installiert werden kann, ohne auf irgendetwas Rücksicht nehmen zu müssen.

tl;dr: Linux ist nicht Windows. Zu verlangen, dass Python diesen Unterschied komplett transparent macht, ist etwas viel verlangt.

[noisefloor]

Hallo,

Nur habe ich eben die Python-Installationen von python.org genommen und wenn es überhaupt etwas zu meckern gäbe dann das voreingestellte X bei den Administratorrechten.

Der allergrößte Nachteil ist, das diese Methode der Installation keinerlei Updatemechanismen kennt und du das jedes Mal manuell selber machen musst.

Zur Installation von Python in Linux habe ich mich am WE versucht,

Welches Linux? Die Pauschalisierung, die danach folgt, ist in der Form falsch. Es kommt allein drauf an, wie die Distro deiner Wahl Python paketiert. Bei Debian und Ubuntu ist es in der Tat so, dass das pip und das tkinter-Modul in separaten Paketen stecken, die man manuell nachinstallieren kann.

das Python "python3" heißen muß,

Guess what - weil du Python 3 nutzt! Bei Ubuntu kannst du für die beiden immer noch unterstützen Releases 20.04 LTS und 22.04 LTS nach wie vor Python 2.7 installieren. Und das wird dann halt mit `python` aufgerufen. Es gibt für Ubuntu aber auch das Paket python-is-python3, nach dessen Installation der Aufruf von `python` das systemseitig installierte Python 3 startet.

Unterm Strich ist das schon alles so gewollt - was natürlich nicht heißt, dass das für jedermann taugt oder jedermann das als "einfach" empfindet.

Der neuste heiße scheiß: uv

Korrekt. Schön, dass es Rust braucht, um den neuen, heißen Paketmanager für Python zu erstellen... *SCNR* Wobei uv einfach ist und auch nicht - aufgrund des Funktionsumfangs muss man sich da ja auch erstmal reinfuchsen. Außerdem kann uv - soweit ich weiß - bei der Modulinstallation noch keine in C geschriebenen Erweiterungen kompilieren.

Gruß, noisefloor