Sticky Post Vorteile/Nachteile der aktuellsten Python Version

[Tholo]

oder eleganter mit f-strings

Code: Alles auswählen

fenster = 1000
main.geometry(f"950x{fenster}")

Hallo,

oder eleganter mit f-strings

Wenn du so was vorschlägst solltest du die Python-Version, mit der das funktioniert, dazu schreiben. Hier im Forum sind genug Leute mit Python 3.4 oder 3.5 oder 2.7 unterwegs. Du kannst nicht stillschweigend voraus setzen, dass alle 3.6 haben.
Gruß, noisefloor

Dazu habe ich einmal folgende Gedanken.
Ich habe die Möglichkeit der F-Strings nicht gekannt. Sehr schöne Funktion. Danke Thomas!
Vielleicht möchtet ihr ein Sticky Post eröffnen, der die Vorteile der Neuerungen der aktuellsten Version darstellt. Ggf. auch eine Diskussion warum man persönlich 3.6 oder doch 3.5 nutzt.
Ich finde es stehts interessant wenn ihr darüber diskutiert. Durch das Lesen der Changelogs alleine, konnte ich als Anfänger zb. diese Funktion nicht fassen.
PEP 498: Formatted string literals Hab ich gelesen aber erst durch den Anstoß von Thomas verstanden.
Wäre das ggf. eine Idee? Gerade auf Hinblick der 3.7 würde ich gerne eure persönlichen Meinungen/Gedanken und Möglichkeiten erfahren.

Greets Tholo

[__blackjack__]

3.7‽ Ich nutze 2.7. (Was übrigens auch noch eine aktuelle Python-Version ist.)

Ansonsten wäre für mich ein Grund für 3.5 und ”gegen” 3.6, dass die 3.5 bei Debian Stretch aus den Paketquellen kommt.

[sls]

Die Idee ist nicht verkehrt, ich habe mich bis vor wenigen Tagen gar nicht mit Typ-Annoationen und F-Strings in Python > 3.6 beschäftigt und hatte Quellcode vorliegen wo ich mich kurz fragte "Was zur Hölle ist das?!"

Im Netz steht viel Müll, gerade im Bezug auf Python. Wenn man hier eine Art Knowledge-Base hätte, würde ich das begrüßen, da ich gerne die Kompetenz des Forums hier anzapfe und für meine Software-Projekte berücksichtige.

[noisefloor]

Hallo,

halte ich für wenig sinnvoll. "Vorteile" kann ja subjektiv sein.

Grundsätzlich _sollte_ jede neue Python Version "besser" sein bzw. Vorteile bieten gegenüber dem Vorgänger.

Abgesehen davon:

Ansonsten wäre für mich ein Grund für 3.5 und ”gegen” 3.6, dass die 3.5 bei Debian Stretch aus den Paketquellen kommt.

+1 - IMHO nutzen vielen Anwender die Python-Version, die ihre Linux-Distro mit bringt oder Anaconda mit installiert hat oder... IMHO haben die meisten Nutzer wenig Interesse, z.B. unter Debian Stretch oder Ubuntu 16.04 Python 3.6 selber zu kompilieren.

Gruß, noisefloor

[__blackjack__]

Neben der Version die eventuell vorinstalliert ist, können auch noch Faktoren wie Verfügbarkeit von Modulen/Packages von Drittanbietern oder die Version(en) von alternativen Python-Implementierungen eine Rolle spielen. Zum Beispiel wenn man Code auch mit IronPython, Jython, PyPy, … nutzen will oder muss.

[nezzcarth]

Ich schreibe teilweise Code, der unter Python 3.4 laufen muss (lokal verwende ich die jeweils aktuelle Version). Am auffälligsten ist das für mich im Zusammenhang mit 'pathlib', da man z.B. für die Verwendung mit dem 'open'-Builtin oder Operationen aus dem 'shutils'-Modul die Pfade in Strings umwandeln muss. In Python 3.5 und 3.6 hat man zunehmend direkten Support für Pathlib Objekte. Das macht den Code etwas schöner zu lesen, ist aber insbesondere beim "Rückportieren" nervig.

[Tholo]

Neben der Version die eventuell vorinstalliert ist, können auch noch Faktoren wie Verfügbarkeit von Modulen/Packages von Drittanbietern oder die Version(en) von alternativen Python-Implementierungen eine Rolle spielen. Zum Beispiel wenn man Code auch mit IronPython, Jython, PyPy, … nutzen will oder muss.

Wieso wird von den Modul Schreibern nicht "verlangt", dass sie die Module aktuell halten? Bei anderen Sprachen wird doch auch mehr mit Abwärtskompatibilität und/oder stetiger Codeverbesserung gearbeitet oder?
Das ist eine ernste gemeinte Frage von einem Hobbymöchtegerncoder.
Ich persönlich kann nicht nachvollziehen, wieso ich mein Projekt nicht auf aktuelle (auch Version 2.7) hole/bringe und so den Support erhalte. Oder zumindest die Forks/Pulls auf Git beachte.
Bin ich zu Blauäugig mit meinen Gedanken?

[__deets__]

Hast du ein Beispiel wo das passiert? Mir wäre keines bekannt. Und das Prinzip gilt eigentlich überall: wenn du einen Treiber für zb Linux suchst, und der ist NICHT mainline sondern außerhalb gepflegt, dann kommt es of vor, das der bei neuen Kerneln zerbricht. Wenn der Treiber im Kernel ist, wird er portiert .

Genauso ist das mit Python Modulen. Ist es in der Standard Bibliothek, wird es gewartet.

Und das ist tatsächlich der kritischste Punkt: ist die Autorin bereit, das Modul zu warten.

Und wenn du zb ein interessantes Modul für mich schreibst - wie kann ich dich denn zwingen, das zu warten? Einen Vertrag haben wir nicht. Also auch keine vereinbarten Strafen. Und wie soll freiwilliges Engagement mit sowas funktionieren?

[Tholo]

Das Beispiel was ich im Kopf hab ist Kivy oder gpiozero, SQL ALchemy (Mag sein dass das ja alle sehr große Projekte sind). Die sind doch daran Interessiert möglichst auf der aktuellen Stufe zu sein oder? Und so oft wie ich in Pip verschiedenste Module updaten "darf" (Ich mag Update und mach die auf Android und Unix immer händisch weil ich es mag) dachte ich, das ist allg Standard. Kann mich natürlich täuschen

[__deets__]

Das ist aber nicht „verlangt“. Natürlich gibt es diese Interessen. Es gibt gut gewartete Module. Was auch immer die Leute motiviert - toll.

Du hast aber behauptet, „andere Sprachen“ wären da besser. DAS sind die Beispiele nach denen ich frage.

[__deets__]

Und zur Frage warum du nicht interessiert sein könntest, dein Modul zu warten, für neue Pythok Versionen: deine Firma benutzt Version X, und du hast privat nicht die Zeit. Oder du kriegst Krebs und hast andere sorgen. Oder. Oder. Oder. Die Motivationen sind vielfältig. Natürlich ist es wünschenswert, das Code gewartet wird. Aber es passiert halt aus tausenden Gründen nicht, und manche davon sind sogar gut.

[__blackjack__]

@Tholo: Die Modulschreiber arbeiten oft auch mit Systemen wie Debian bei dem ”nur” 3.5 in den Paketquellen ist. Und rückwärtskompatibel sind die Major-Versionen ja auch. Dann kann es Module/Packages geben, die den Sprung auf 3.x nicht gemacht haben. Oder eben Projekte die Jython einsetzen wo es keine 3.x-Version gibt. Dann gibt's CentOS das stabil ist und sehr lange auf den gleichen Versionständen bleibt. Und dann eventuell auch noch die ein oder andere Hardware (NAS beispielsweise) wo manchmal *wirklich* alte Python-Versionen drauf sind. Bei Software wo Python eingebettet ist, ist man auf den Anbieter der Software angewiesen, ob/wann der eine neuere Version integriert.

[__deets__]

Bei Software wo Python eingebettet ist, ist man auf den Anbieter der Software angewiesen, ob/wann der eine neuere Version integriert.

Wir sind einer dieser Anbieter. Und es ist auch ein reziprokes Verhältnis: wenn wir “einfach” die python Version updaten (akut immer noch 2.7) zerbricht viel Code von Dritten, über den wir keinerlei Kontrolle haben. Aber unseren Kunden tut das dann weh. Also will das wohl überlegt sein.

[Tholo]

@Deets
Subjektive Einschätzung! Hab ans Handy und die Apps und meine Ubuntu PPA´s gedacht. Aber wahrscheinlich hab ich mich da wirklich getäuscht und das is eher BugFixing.

@All
Ich kann eure Punkte nachvollziehen, hatte aber wahrscheinlich den falschen Ansatz. ICH!Persönlich! würde immer die neuste Version verwenden wollen. Hab auch bei meinen RK3399 Singleboards sofort 3.6 drauf gemacht (von 3.3 glaub ich) weil ICH mich mit der Version nicht zufrieden stellen wollte. Hab wahrscheinlich nicht daran gedacht, das der allg. User das nimmt was er bekommt und der Updatewahn eher mein Ansinnen ist und nicht übertragen werden darf.

Trotzdem werd ich zu 3.7 mal einen Post aufmachen. Da ich mal versuche werde die Nooby Ansichtsweise zu projizieren und dann gespannt bin auf eure Kommentare.
Erhellend war das mal wieder für mich, da meine Probleme, Ansichten und Denkweisen wiedermal nicht auf die Zielgruppe passt...Mal gut das ich Pädagoge bin und diese Überlegungen täglich treffen muss