Ist Python 3.12 abwärts kompatibel zu 3.11 und 3.10

[alfware17]

Wollte noch mal als Erfolgsmeldung geben, daß ich das nun auch im Linux eingerichtet bekommen habe - VSC und PyCharm in Linux Mint und LMDE (weil jeweils ein anderes Python 3.11 bzw 3.12).

Die größte Hilfe kam aus einem reinen Linux-Forum und beinhaltete im Wesentlichen
sudo apt install python3-pip
sudo apt install python3-venv
sudo apt install python3-tk

Dann noch das Einrichten der .venv und Aktivieren (per Hand), am besten vor der Installation von VSC und PyCharm. Wobei ich in 50% der Fälle darauf verzichten konnte und das VSC für mich erledigt hat, es gehen aber beide Wege. Schlau wäre dann nur, daß man PyCharm erst als 2.IDE aufruft, dann kann die Einstellungen und Projekt vom VSC übernehmen/importieren.

Um noch mal zum Ausgang meiner Frage zurückzukommen:
ich habe in Win10 Python 3.11 und in Win 11 Python 3.12 genommen
in Linux Mint 21.3 war Python 3.11 drin und in LMDE 6 war Python 3.12 drin.

Unterschiede sah/seh ich keine. meine gefragte Abwärtskomatibilität ist also da.

Mit den drei oben angegebenen Befehlen wird im Linux "gleiche Bedingung" hergestellt, d.h. VSC kann .venv einrichten und man kann PIP auf dem Terminal benutzen. Warum das nicht standardmäßig so ist, mag jeder anders beantworten, ich habe jedoch öfters auf Linux geflucht als auf Windows.

Was die "Fallen" angeht, steht es auch ausgeglichen - in WIndows darf man Python nicht mit den (voreingestellten!) Adminrechten installieren, und man muß wissen, daß gewisse DLL vom VS Runtime vorausgesetzt werden. In Linux dagegen ist das "vorinstallierte" Python leider nicht vollständig und man muß es erweitern. Hier im Thread haben einige auch erklärt warum - überzeugen tut mich das als Anwender nicht.
Und ach ja, was dem Linux sein APT ist, ist im Windows der Store - ich kann nur davon abraten, Python, Pycharme oder VSC von dort zu installieren - das ging schief. Zum Glück ist mir der Store eh bei WIn 10 seit kurzem gesperrt, keine Versuchung.

Ich habe in den vergangenen Wochen nun ca 30 Varianten als Virtual Box Installationen probiert und die meisten eingestampft, die o.g. 4 wie gesagt behalten. Nicht auszudenken ich hätte das an realen PCs versucht....

[Dennis89]

Sorry, aber ich glaube immer noch das du irgendwas falsch machst. (oder vllt auch ich)
PyCharm erstellt selbstständig Entwicklungsumgebungen und die kann man auch außerhalb von PyCharm nutzen. Genauso kann ich auch manuell eine erstellt und PyCharm nutzt diese.

Noch als Hinweis, falls du mal was anderes als Mint nutzen willst. `apt` ist nicht der Store von Linux, das ist eine Paketverwaltung die bei manchen Linuxdistributionen dabei ist. Wenn du mal sowas wie Fedora nutzt, dann nennt sich das `dnf` und nicht mehr `apt`.

Eventuell haben wir auch verschiedene Grundeinstellungen. Ich nutze zwar lieber Linux als Windows, aber auch unter Windows war das installieren von Python 3 Mausklicks und es gab keine „Fallen“.

Grüße
Dennis

[noisefloor]

Hallo,

Und ach ja, was dem Linux sein APT ist, ist im Windows der Store

Das ist hochgradiger Unfug und von der Aussage her ziemlich falsch. Nur zu Korrektur, falls den Thread noch mal jemand liest oder der Bot eines LLM mal auf die Idee kommt, die Aussagen in diesem Thread als Trainingsdaten zu nehmen.

APT ist eine (von grundsätzlich mehreren existierenden) Paketverwaltung für das _gesamte_ System, apt wird u.a. von Debian, Ubuntu und allem, was darauf aufbaut, genutzt. Fedora, Suse und Arch sowie etliche andere Linux-Distributon nutzen kein APT für die Paketverwaltung. Der Windows Store ist nur für Anwendungssoftware und nicht für die Systemaktualisierung.

@alfware17: es gibt nicht _das_ Linux. Du musst schon zwischen Linux (=dem Betriebssystem) und dem mannigfaltigen Ökosystem an Linux-Distributionen unterscheiden. Die Verallgemeinerung, die du bzgl. der Nutzung des Worts "Linux" betreibst, ist schlicht falsch.

Gruß, noisefloor

[nezzcarth]

Um noch mal zum Ausgang meiner Frage zurückzukommen:
ich habe in Win10 Python 3.11 und in Win 11 Python 3.12 genommen
in Linux Mint 21.3 war Python 3.11 drin und in LMDE 6 war Python 3.12 drin.

Unterschiede sah/seh ich keine. meine gefragte Abwärtskomatibilität ist also da.

Die Unterschiede zwischen den einzelnen Python-Versionen sind in den jeweiligen Changelogs aufgelistet, s. z.B. das für 3.12: https://docs.python.org/3/whatsnew/3.12.html
So sind zum Beispiel in 3.12 einige Dinge mit f-Strings möglich, die frühere Versionen nicht unterstützen. Structual Pattern Matching kam mit 3.10. Das sind aber aller Sachen, die vmtl. erst auf einem höheren Level relevant werden. Änderungen kann es immer geben, sowohl in der Sprache als auch in der Bibliothek. Das ist aber in der offiziellen Doku alles gut beschrieben.

überzeugen tut mich das als Anwender nicht.

Die Formulierung spiegelt für mich einen Kern der Problematik wider: Wenn du Python unter einer Linux-Distribution verwenden möchtest, bist du Entwickler (oder Admin) und musst die (von Windows gewohnte) Anwender-Rolle ablegen. Moderne Linux Distros bemühen sich, von Windows und MacOS kommenden "Anwendern" entgegen zu kommen. Aber Software-Entwicklung ist halt nun mal das, wofür Unix ursprünglich mal erfunden wurde und was neben ein paar anderen Feldern (Server, Embedded, etc.) auch das Kerngeschäft von Linux als unixoidem System ist. Auch wenn Python verglichen mit anderen Sprachen schon vergleichsweise lange relativ guten Windows-Support aufweist, merkt man der Sprache an diversen Stellen an, dass sie insbesondere eine starke Verbindung zu Unix und Linux hat, wurde sie doch entworfen als Sprache "that would appeal to Unix/C hackers" bzw. mit der "intended audience of experienced Unix/C programmers" (Zitat, Guido van Rossum, https://www.python.org/doc/essays/foreword/). In meinem Umfeld verwenden eigentlich alle, die professionell Python programmiern, eine Linux-Distribution als Entwicklungsystem. Und ich höre da auch keine Klagen, dass das besonders kompliziert wäre, sondern umgekehrt, dass es besonders gut geht (für Entwickler). Man muss sich mit den vielleicht ungewohnten Arbeitsweisen eben vertraut machen und auf die einlassen. Insofern kann ich mich über deine Aussage, dass es "unter Linux "alles so schlecht funktionieren würde jedenfalls nur wundern.

[DeaD_EyE]

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.

Es werden keine Rust-Abhänggkeiten benötigt. Kein Compiler und auch keine Runtime.
Die Binaries sind statisch kompiliert und die einzige Abhängigkeit ist glibc.

Verknüpft Rust statisch?
Rust verknüpft standardmäßig alles außer glibc (und libgcc) statisch . Seit Rust 1.19 können Sie die C-Runtime (CRT) statisch verknüpfen, um diese unter Windows sehr häufige Situation zu vermeiden: Das Programm kann nicht gestartet werden, weil VCRUNTIME140.02.08.2015

Außerdem kann uv - soweit ich weiß - bei der Modulinstallation noch keine in C geschriebenen Erweiterungen kompilieren.

Scheint zu funktionieren. Ich muss mich aber auch noch einarbeiten.
Musste gerade feststellen, dass ich die ganze Zeit den falschen Interpreter verwendet habe
Ja, wenn man Python 30 mal installiert hat, kann man durcheinander kommen.
Ich nutze fast immer pyenv, lasse aber die lokale Version generell auf system stehen, damit andere Software die Python und die Pakete von Arch-Linux nutzt.

[alfware17]

Hallo,

Und ach ja, was dem Linux sein APT ist, ist im Windows der Store

Das ist hochgradiger Unfug und von der Aussage her ziemlich falsch. Nur zu Korrektur, falls den Thread noch mal jemand liest oder der Bot eines LLM mal auf die Idee kommt, die Aussagen in diesem Thread als Trainingsdaten zu nehmen.

APT ist eine (von grundsätzlich mehreren existierenden) Paketverwaltung für das _gesamte_ System, apt wird u.a. von Debian, Ubuntu und allem, was darauf aufbaut, genutzt. Fedora, Suse und Arch sowie etliche andere Linux-Distributon nutzen kein APT für die Paketverwaltung. Der Windows Store ist nur für Anwendungssoftware und nicht für die Systemaktualisierung.

@alfware17: es gibt nicht _das_ Linux. Du musst schon zwischen Linux (=dem Betriebssystem) und dem mannigfaltigen Ökosystem an Linux-Distributionen unterscheiden. Die Verallgemeinerung, die du bzgl. der Nutzung des Worts "Linux" betreibst, ist schlicht falsch.

Gruß, noisefloor

Es geht mir - nur - um die Funktion als Bibliothek von Auswendungen, aus denen ich auswählen kann/muß. Ähliches gibt es ja auch bei Android und i-mac oder woanders. Man wählt die Anwendungen aus, lädt sie runter usw. Im Gegensatz dazu, wenn ich meine Anwendung in Form einer binary schon mitbringe - im Windows als EXE oder MSI, im Linux zB als DEB oder RPM oder im Android als eigene APK (i-mac keine Ahnung). Natürlich ist die Sache bei Linux noch anpassbar und konfigurierbar - deswegen ist die grundsätzliche Unterscheidung aber nicht Zitat "hochgradiger Unfug".

Und ja es gibt verschiedene Linuxe, ich denke man kann das grundsätzlich schon mal zusammenfassen und Windows gegenüberstellen oder i-mac oder Android oder ... (ich komme zB beruflich noch aus einer ganz anderen Betriebssystem-Ecke). Wenn ich das Ding Linux nenne und nicht Linux Mint Cinnamon oder LMDE Mate xyz dann möchte ich nur das Allgemeine nennen und nicht noch wieder auf Feinheiten einer speziellen Distribution und Diskussion darüber. Wenn ich mit einem Linux-Befehl in Ubuntu oder Debian oder sonstwo Schwierigkeiten habe, dann ist das immer noch (viel näher) zusammen als wenn ich dem Windows und eine dortige Shell gegenübersetze,

[alfware17]

Um noch mal zum Ausgang meiner Frage zurückzukommen:
ich habe in Win10 Python 3.11 und in Win 11 Python 3.12 genommen
in Linux Mint 21.3 war Python 3.11 drin und in LMDE 6 war Python 3.12 drin.

Unterschiede sah/seh ich keine. meine gefragte Abwärtskomatibilität ist also da.

Die Unterschiede zwischen den einzelnen Python-Versionen sind in den jeweiligen Changelogs aufgelistet, s. z.B. das für 3.12: https://docs.python.org/3/whatsnew/3.12.html
So sind zum Beispiel in 3.12 einige Dinge mit f-Strings möglich, die frühere Versionen nicht unterstützen. Structual Pattern Matching kam mit 3.10. Das sind aber aller Sachen, die vmtl. erst auf einem höheren Level relevant werden. Änderungen kann es immer geben, sowohl in der Sprache als auch in der Bibliothek. Das ist aber in der offiziellen Doku alles gut beschrieben.

überzeugen tut mich das als Anwender nicht.

Die Formulierung spiegelt für mich einen Kern der Problematik wider: Wenn du Python unter einer Linux-Distribution verwenden möchtest, bist du Entwickler (oder Admin) und musst die (von Windows gewohnte) Anwender-Rolle ablegen. Moderne Linux Distros bemühen sich, von Windows und MacOS kommenden "Anwendern" entgegen zu kommen. Aber Software-Entwicklung ist halt nun mal das, wofür Unix ursprünglich mal erfunden wurde und was neben ein paar anderen Feldern (Server, Embedded, etc.) auch das Kerngeschäft von Linux als unixoidem System ist. Auch wenn Python verglichen mit anderen Sprachen schon vergleichsweise lange relativ guten Windows-Support aufweist, merkt man der Sprache an diversen Stellen an, dass sie insbesondere eine starke Verbindung zu Unix und Linux hat, wurde sie doch entworfen als Sprache "that would appeal to Unix/C hackers" bzw. mit der "intended audience of experienced Unix/C programmers" (Zitat, Guido van Rossum, https://www.python.org/doc/essays/foreword/). In meinem Umfeld verwenden eigentlich alle, die professionell Python programmiern, eine Linux-Distribution als Entwicklungsystem. Und ich höre da auch keine Klagen, dass das besonders kompliziert wäre, sondern umgekehrt, dass es besonders gut geht (für Entwickler). Man muss sich mit den vielleicht ungewohnten Arbeitsweisen eben vertraut machen und auf die einlassen. Insofern kann ich mich über deine Aussage, dass es "unter Linux "alles so schlecht funktionieren würde jedenfalls nur wundern.

Ich bin kein professioneller Programmierer (nicht mehr und auch nie im PC-Umfeld). Und ich sage zu Linux auch nicht "schlecht" sondern nur spröde, oft unerwartet und (für mich) kompliziert an Stellen, wo ich es nicht dachte auf Probleme zu stoßen. Das geht los mit notorischer Groß-/Kleinschreibung, die mich ständig zwingt meine Quelltexte anzupassen wenn ich zu von Windows nach Linux portiere,
ok weil ich vorher schlampig war und es in Windows trotzdem ging und/oder weil die Quellen uralt sind. Weiterhin Zeichensatzprobleme oder Berechtigungen oder Pfade und Sichtbarkeiten. Versteht mich nicht falsch - das hat alles seinen Sinn, ist aber oft nur lästig und einschränkend und macht mehr Arbeit.

Zudem gebe ich gerne zu, habe ich in Python wahrscheinlich viel weniger Ahnung als gut ist. Es ist aber auch nur eine von vielen Sprachen für mich und ich habe die oben angerissenen Probleme jedesmal, wenn ich von Windows aus den Ausflug nach Linux mache - sei es in Java, Lazarus, beim Android Studio oder sonst was. Ich versuche, meine Anwenungen möglichst zu portieren ein schönes Paket daraus zu machen aber ich bin eben in der Denkweise vom Windows her verhaftet, daß ich der einzige und möglichst umfassende Nutzer bin und alles kann und darf, schließlich ist es mein Rechner.... Linux ist anders ja ich weiß, aber für mich ist es oft spröde und lästig. Nichtsdestotrotz beschäftige ich mich seit 12 Jahren damit und kämpfe und nehme einiges auf mich, weil ich es gern mache und die Herausforderung liebe.

[noisefloor]

Hallo,

Das geht los mit notorischer Groß-/Kleinschreibung, die mich ständig zwingt meine Quelltexte anzupassen wenn ich zu von Windows nach Linux portiere,

Ob eine Programmiersprache "case sensitive" ist oder nicht hat nichts mit dem Betriebssystem zu tun, auf dem es läuft. Python ist immer case sensitive, unter Windows genau so wie unter Linux. SQL ist z.B. nicht case-sensitve, weder unter Windows noch unter Linux.

Es werden keine Rust-Abhänggkeiten benötigt. Kein Compiler und auch keine Runtime.

Habe ich auch nicht behauptet. Rust kann ja zu statischen gelinkten executable binaries kompiliert werden. Was ist meine ist, dass es bisher keiner geschafft hat, eine gleichwertiges Programm in Python (oder eine anderen Sprache) zu erstellen.

Gruß, noisefloor

[alfware17]

Hallo,

Das geht los mit notorischer Groß-/Kleinschreibung, die mich ständig zwingt meine Quelltexte anzupassen wenn ich zu von Windows nach Linux portiere,

Ob eine Programmiersprache "case sensitive" ist oder nicht hat nichts mit dem Betriebssystem zu tun, auf dem es läuft. Python ist immer case sensitive, unter Windows genau so wie unter Linux. SQL ist z.B. nicht case-sensitve, weder unter Windows noch unter Linux.

Es werden keine Rust-Abhänggkeiten benötigt. Kein Compiler und auch keine Runtime.

Habe ich auch nicht behauptet. Rust kann ja zu statischen gelinkten executable binaries kompiliert werden. Was ist meine ist, dass es bisher keiner geschafft hat, eine gleichwertiges Programm in Python (oder eine anderen Sprache) zu erstellen.

Gruß, noisefloor

Lazarus/Pascal ist auch nicht case-sensitive und da komme ich (am PC) her. Ich meinte zB einfache Unit-Namen oder (in Shells) Verzeichnisse/Dateien, die plötzlich nicht mehr gefunden werden. Ja meine Schlampigkeit - Linux hat ja recht, nur ist es ungewohnt spröde. Genauso wie ein ./befehl wenn man denn nun schon im Verzeichnis von befehl ist und das im Windows per Definition im Pfad liegt, in Linux aber nicht..

[__blackjack__]

@alfware17: Linux ist halt von Anfang an ein Mehrbenutzersystem und man hat ein bisschen auf Sicherheit geachtet, so dass nicht einfach im aktuellen Arbeitsverzeichnis was ausgeführt wird, von dem man überrascht werden kann. So etwas war unter DOS und den ersten Windows-Versionen kein grosses Problem, und deswegen gibt es diesen Schutz in der Form unter Windows nicht.