Mit Java fÀngt man beim rechten Bild an und es bleibt auch dabei.
ich_iel
Die offizielle Zweigstelle von ich_iel im Fediversum.
Alle Pfosten mĂŒssen den Titel 'ich_iel' haben, der Unterstrich darf durch ein beliebiges Symbol oder Bildschriftzeichen ersetzt werden. Ihr dĂŒrft euch frei entfalten!
đ± Empfohlene Schlaufon-Applikationen fĂŒr Lassmich
Befreundete Kommunen:
Regeln:
1. Seid nett zueinander
Diskriminierung anderer Benutzer, Beleidigungen und Provokationen sind verboten.
2. Pfosten mĂŒssen den Titel 'ich_iel' oder 'ich iel' haben
Nur Pfosten mit dem Titel 'ich_iel' oder 'ich iel' sind zugelassen. Alle anderen werden automatisch entfernt.
Unterstrich oder Abstand dĂŒrfen durch ein beliebiges Textsymbol oder bis zu drei beliebige Emojis ersetzt werden.
3. Keine HochwÀhl-Maimais oder (Eigen)werbung
Alle Pfosten, die um HochwĂ€hlis bitten oder Werbung beinhalten werden entfernt. Hiermit ist auch Eigenwerbung gemeint, z.b. fĂŒr andere Gemeinschaften.
4. Keine BildschirmschĂŒsse von Unterhaltungen
Alle Pfosten, die BildschirmschĂŒsse von Unterhaltungen, wie beispielsweise aus WasistApplikaton oder Zwietracht zeigen, sind nicht erlaubt. Hierzu zĂ€hlen auch Unterhaltungen mit KIs.
5. Keine kantigen BeitrÀge oder Meta-BeitrÀge
ich_iel ist kein kantiges Maimai-Brett. Meta-BeitrĂ€ge, insbesondere ĂŒber gelöschte oder gesperrte BeitrĂ€ge, sind nicht erlaubt.
6. Keine ĂberfĂ€lle
Wer einen Ăberfall auf eine andere Gemeinschaft plant, muss diesen zuerst mit den Mods abklĂ€ren. Brigadieren ist strengstens verboten.
7. Keine Ă40-Maimais
Maimais, die es bereits in die WasistApplikation-Familienplauderei geschafft haben oder von RĂŒdiger beim letzten Stammtisch herumgezeigt wurden, sind besser auf /c/ichbin40undlustig aufgehoben.
8. ich_iel ist eine humoristische Plattform
Alle Pfosten auf ich_iel mĂŒssen humorvoll gestaltet sein. Humor ist subjektiv, aber ein Pfosten muss zumindest einen humoristischen Anspruch haben. Die AtmosphĂ€re auf ich_iel soll humorvoll und locker gehalten werden.
9. Keine Polemik, keine KöderbeitrÀge, keine Falschmeldungen
BeitrĂ€ge, die wegen Polemik negativ auffallen, sind nicht gestattet. Desweiteren sind Pfosten nicht gestattet, die primĂ€r Empörung, Aufregung, Wut o.Ă. ĂŒber ein (insbesonders, aber nicht nur) politisches Thema hervorrufen sollen. Die Verbreitung von Falschmeldungen ist bei uns nicht erlaubt.
Bitte beachtet auch die Regeln von Feddit.org
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.
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.
(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.
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.
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.
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.
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.
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.
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!
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, bool
ist eine Subklasse von int
.
assert issubclass(bool, int)
Ja, das aber war eher so gemeint, dass es total unerwartet ist.
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
[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]
Verstehe ich so gar nicht, meine Erfahrung mit Pythđ€ą warte kurz đ€ź
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.
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 annotations
machen und dann Klassen vor ihrer Deklaration verwenden.
Siehe auch dieser StapelĂberlauf Faden: https://stackoverflow.com/questions/61544854/from-future-import-annotations
Ich sehe, selbst nicht checken und dann ist die Programmiersprache das Problem, nice.
durchschnittlicher pyton benutzer gegen umschreiben in rost chad
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)?
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.