Kontext: Ich kann bis jetzt nur Java und will ein Programm schreiben um die Metadaten meiner Musikbibliothek zu verändern. Die Bibliothek die das Möglich macht unterstützt nur Python. Anfangs war ich echt positiv von der Einfachheit überrascht, aber mittlerweile kann ich den Hass auf Python sehr stark verstehen. Spätestens bei den Ersten Typisierungsfehlern lernt man stark typisierte Sprachen wie Java zu schätzen.
Mit Java fängt man beim rechten Bild an und es bleibt auch dabei.
Ich lerne grade die (Programmier-)Arbeit an einem Tool, welches zwar in Java geschrieben ist, aber Python als Skriptsprache verwendet… Python 2.
Außerdem muss man den Testserver für das Testen von Änderungen rebooten, wir haben aber nur einen Server für ca. 6 Leute.
Ich freue mich schon auf die Arbeit.
(Eigene) VM und automatisierte Tests für beste Ergebnisse.
Ja aber die Lizenzen…
Das klingt als wärst du in der Hölle. Hoffentlich wird’s bald besser.
Jython?
Ich hasse Jython, wie kann man den so viele Jahre den Sprung auf Python 3 verpassen? >_>
Das kann sein. Aber das ist nur in dem Tool integriert, das wir eingekauft haben… Vor ca. 5 Jahren… Als Python 2 schon fast eol war.
[Zensierte abfällige und zynische Bemerkungen über Python]
[Sarkastisch formulierter Vorwurf des mangelnden Verständnisses von Python]
[Patzige Antwort über GIL, furchtbare Syntax und brechende Veränderungen]
Python ist doch angenehm. Und die meisten typfehler sagt dir schon die Entwicklungsumgebung noch vor dem run.
Für kleinere Sachen ist python sowieso spitze weil wortarm und für größeres solltest du sowieso Tests schreiben um Fehler auszuschließen. Ob Python oder Java ist dann auch wurst
Du brauchst mypy in deinem Leben.
Oder die Hartkern-Variante: in Rust schreiben und via Python konsumierbar machen mit PyO3
Im Prinzip ja, aber für ein One-Off-Skript zum Anpassen von Metadaten wären mir das dann wahrscheinlich doch zuviele Typen.
Was macht das denn genau?
Python kann mittlerweile statische type hints. Dabei schreibst du nur die intention (“ein int geht rein, ein bool kommt raus”). Mypy warnt dich dann wenn du in irgendeine Funktion Daten reinstecken willst, die nicht reinpassen. Zur Laufzeit werden die type gibts ignoriert. Je nachdem wen man fragt ist das entweder eine total flexible Art Typen so stark oder so lax wie man möchte in seinen code zu integrieren, oder es ist nutzlos da es keine laufzeitsicherheit bietet.
Was ich gelernt habe ist, dass du Python so schreiben solltest als wäre es typisiert. Hab bisher nur Godot Script geschrieben, aber das ist stark an Python angelehnt, deshalb hoffe ich, dass sich das übertragen lässt.
Du kannst so ziemlich allem einen Typ geben und das so forcieren. Dann solltest du nicht durcheinander kommen.
Hilft einem wenig, wenn man libraries verwendet.
Das Type-Checking kann aber leider nicht mit strikt typisierten Sprachen mithalten und erfordert oft manuelle Checks, die eigentlich komplett überflüssig sind. Liegt natürlich auch daran, dass man die Typen theoretisch ständig ändern kann, egal was dran steht.
Und was schlimmer ist: Fehler in den Annotations führen teilweise dazu, dass dir vermeintliche Folgefehler an komplett anderen Stellen angezeigt werden, als sie wirklich liegen. Z.B. dass deine Variable an gegebener Stelle den falschen Typ hat, was aber eigentlich daran liegt, dass an anderer Stelle was kompatibles aber verkehrtes zugewiesen wurde, wobei du ursprünglich die Annotation vergessen hast, weil an der Stelle ein Type-Hint aufgeplopt ist, was den ersten Fehler widerum unsichtbar macht.
Klingt vielleicht konstruiert, aber eine Annotation vergisst man schnell und wenn, dann wird es schnell ärgerlich.
Lustiger Fakt: Python ist stark typisiert (aber dynamisch), aber booleans sind trotzdem integer:
assert isinstance(True, int)War die einzige Falle in die ich bis jetzt rein gelaufen bin, die wirklich gemein ist.
Und typehints im Zusammenhang mit cython. Und cython eigenheiten generell.
Python ist stark typisiert (aber dynamisch), aber booleans sind trotzdem integer
Das ist kein Widerspruch,
boolist eine Subklasse vonint.assert issubclass(bool, int)Ja, das aber war eher so gemeint, dass es total unerwartet ist.
Wisst ihr eigentlich wie gut es sich anfühlt durch eine Kommentarsektion zu blättern bei der bei fast jedem Unter-Faden etwas steht zu dem mensch sich äußern könnte; aber dann bewusst zu entscheiden, dass das echt nicht nötig ist und auch andere Menschen das genau so gut unter sich ausdiskutieren können; und dann halt einfach nicht auf irgendwelche Details eine Reaktion zu pfostieren, sondern einfach nur zu chillen (und vielleicht einen Meta-Kommentar abzusetzen, aber mehr nicht)?
Du machst es falsch. Sorry, wenn ich hier pauschal werde. Aber so eine Aufgabe ist wirklich trivial in Python. Ich verstehe, das man da verwirrt ist, wenn man von anderen Sprachen kommt, aber du musst einfach ein bisschen umdenken.
Das ganze Ding ist nicht enorm schwer, aber Python hat einfach nicht die Komplexität die ich brauche um mich wohl zu fühlen. Zudem finde ich das ganze Syntax teils sehr komisch.
Da kann Python nun aber nix dafür.
Das ist so. Sorgt trotzdem dafür, dass ich Python auf keinen Fall für Größere Projekte nutzen werde.
Das ist dein gutes Recht, Brudi.
durchschnittlicher pyton benutzer gegen umschreiben in rost chad
Python ist eigentlich ganz nett. Man muss nur pragmatisch rangehen und auf jeden Fall die Community und die merkwürdigen Säue, die die regelmäßig durchs Dorf treiben, ignorieren…
Gerade für kleinere Sachen ist das so sperrigen Sprachen wie Java deutlich überlegen, wenn man sich erstmal reingefunden hat.
Wie bei allen Programmiersprachen, ist es natürlich sinnvoll, gescheite Werkzeuge zu benutzen.
Für kleine Sachen ist Python geil, da hört es aber auch schon auf.
Sag das Home Assistant, es scheint für die recht gut zu funktionieren.
Papperlapap, für fast alles was scripting ist ist python toll.
E.g. conan2 ist pythonbasiert. Testsuites kann man damit auch betreiben. Und es erlaubt dir z.b.PS nicht zu können wenn du plattformunabhängigkeit brauchst.
Für simple Sachen ist es gut, aber komplexe Sachen machen absolut keinSpaß, einfach weil Python zu blöd ist zu verstehen was ich tue wenn ich meine ganzen Klassen nicht an den Anfang schreiben will. Das macht das ganze Ding einfach u übersichtlicher und zwingt einen dazu eventuell Sachen umzustrukturieren, obwohl es dadurch dann unübersichtlicher wird.
Du kannst am Anfang
from __future__ import annotationsmachen und dann Klassen vor ihrer Deklaration verwenden. Siehe auch dieser StapelÜberlauf Faden: https://stackoverflow.com/questions/61544854/from-future-import-annotations
Python hat viele tolle Eigenschaften, manchmal fällt es nur schwer sie zu sehen.
Warum nimmst du nicht einfach taglib? Die library hat bindings für viele sprachen
Das ist das erste mal, dass ich überhaupt mit libraries Arbeite, also kenne ich den ganzen Kram noch nicht. Wenn ich mein script final fertiggestellt habe kommt das ganze vielleicht noch in Java, wo ich dann taglib nutze.
Python ist stark Typisiert. Was du meist ist dynamisch - statisch.
Ich mag dynamische Typisierung. Ich möchte nicht an jeder Stelle dem Programm erklären müssen, dass ich eine Fließkommazahl speichern möchte, wenn ich eine Ganzzahl mit einer Fließkommazahl multipliziert habe. Ich möchte auch nicht bei großen 2D-Arrays Speicherplatz fressen, weil keine Spalten mit verschiedneen Typen zugelassen werden und alles in Fließkomma, oder noch schlimmer in Text umgewandelt werden muss.
a) Bei statisch typisierten Sprachen geht der Trend auch stark dort hin, dass der Complier für Dich die Typen ermittelt - zur Compile-Zeit. Auch haben viele davon auch die Möglichkeit punktuell dynamisch zu arbeiten, an genau den Stellen, wo man es braucht.
b) Oh wow, du möchtest nicht “Speicherplatz fressen”. Dann nimm eine Sprache / Werkzeug / Library, die nicht pro gespeichertem Wert einzeln tracken muss, von welchem Typ sie ist. Hier zahlst Du in dynamischen Sprachen immer einen Performance-Overhead. Deswegen wird z. B. in Python viel Number crunching auch nicht in Python selbst gemacht, sondern in NumPy
ad b) nicht nur Performance-Overhead, sondern eine dynamisch typisierte Sprache macht das ja auch nicht umsonst, da wird irgendwo ein Typen-Bit oder Byte rumfliegen.
Ich glaube, dass hinter der vorangehenden (also nicht deiner) Aussage, die Unkenntnis über effiziente Speichermodelle steht. Ein auf fp32 basiertes Modell ist für hohen Durchsatz garantiert geeigneter als irgendwas gemischtes. Deswegen ist der Speicherplatz egal, das wird eh alles in den Cache gerammelt und die sind groß genug. Und bei Nudelmaschinen (SIMD) muss man eh Homogenität gewährleisten.
Fünfzehn Extrapunkte für den Begriff Nudelmaschine für SIMD
Seit Jahren lasse ich den fallen und seit Jahren scheint das niemand zu registrieren. Mir geht das Herz auf - danke!
Provokativer Nimm: Wenn du dynamische Typisierung in einer Matrix brauchst, ist dein Programm vermutlich nicht besonders performant.
Genau wegen sowas würde ich Python nie für mehr als einfache Skripte nehmen, aber da stehe ich vermutlich eher allein auf weiter Flur.
Sowas macht in modernem Python auch niemand. Dem type checker für solche Konstrukte einen Typ beizubringen ist quasi unmöglich. Wer außerhalb von winzigen skripten keine type hints nutzt, machts mMn falsch.
Naja, ich habe ja direkt auf jemanden reagiert, der das offensichtlich tut, also so ganz niemand stimmt wohl nicht.
dynamische Typisierung
“Spalten mit verschiedenen Typen” klingt für mich stark nach Tabelle, a.k.a. Excel-Tabelle oder ne Art Datenbank-Table.
In einer strikten Typisierung wäre der Typ des Feldes einer n-dimensionalen Matrix bereits bekannt, was natürlich deutliche Vorteile hinsichtlich ihrer Abarbeitung in kritischen Bereichen erlauben würde. Bei “Spalten mit verschiedenen Typen” klingt das eher nach einem generischen Datenmodell.
Ich sehe, selbst nicht checken und dann ist die Programmiersprache das Problem, nice.
