Wer von euch nutzt Python?



  • Ethon_ schrieb:

    Deshalb nur für sehr kleine Utility-Scripts. Angenehmer als Bash-Scripts.

    Jup. Aber 'Destruktoren' musste ich schon irgendiwie in Bash 'dazuerfinden', wenns ein paar mehr Zeilen werden. Sonst hab ich ja danach keinen definierten Status, sonst kann ich nicht als Aufrufer reagieren.

    janitors=()
    pushJanitor () {
    	janitors[${#janitors[@]}]="$@"
    	echo "janitors=${janitors[@]}"
    }
    popJanitor () {
    	unset janitors[${#janitors[@]}-1]
    	echo "janitors=${janitors[@]}"
    }
    onExit () {
    	for (( idx=${#janitors[@]}-1 ; idx>=0 ; idx-- )) ; do
    		$(${janitors[idx]})
    	done
    }
    trap onExit exit
    
    export tmp_dir=$(mktemp -d)
    pushJanitor "rmdir ${tmp_dir}"
    
    truncate --size=6G ${tmp_dir}/img
    pushJanitor "rm ${tmp_dir}/img"
    
    …
    

    Ich bin ein Freund, nichtDringendNotwendige Technologien zu vermeiden, erstmal auf zum Beispiel Bash bleiben und nicht ohne Not auf eine der 12 quasi überall installierten Alternativen ausweichen.

    Mein größtes Bash-Script hat 4k, mein größtes Python-Script hat 15k. Das Bash-Script ist wartbar. Das Python-Script könnte und sollŧe durch ein universal makefile ersetzt werden.



  • SeppJ schrieb:

    Andromeda schrieb:

    Wo liegen echte Vorteile von Phyton, die man bei anderen Interpretersprachen vergeblich sucht?

    Unter den Interpretersprachen ist es doch schon mit Abstand das lesbarste und mächtigste, was es so gibt.

    Smalltalk gibt's auch noch, und schon viel länger als Python.



  • versionsnummer schrieb:

    SeppJ schrieb:

    Andromeda schrieb:

    Wo liegen echte Vorteile von Phyton, die man bei anderen Interpretersprachen vergeblich sucht?

    Unter den Interpretersprachen ist es doch schon mit Abstand das lesbarste und mächtigste, was es so gibt.

    Smalltalk gibt's auch noch, und schon viel länger als Python.

    Jo. Smalltalk ist auch viel viel einfacher. Keine sinnlose Trennung zwischen Objekten und Objekten, wobei erstere Instanzen sind und zweitere Dinge sind.
    Smalltalk war nie schnell, also noch lahmer als Java, das Bißchen strippen hat gerade mal gar nix gebracht.
    Python kriegt, wenn ich das letzte LWN recht in Erinnerung habe, einen jitter.
    Wenn ich als König von der Welt die Wahl treffen müsste, ob Python oder Smalltalk, dann wäre ich für Smalltalk; ich meine sogar, daß Smalltalk von einem jitter viel mehr boost hätte, als Python überhaupt kann.



  • volkard schrieb:

    Ich benutze Python fast täglich. Aber nur für kleine Sachen, denn Python bietet im Vergleich zu C++ überhaupt keine Unterstützung bei der Fehlervermeidung.

    Was genau meinst Du damit? Meinst Du damit das dynamic typing? Oder etwas, was darüber hinaus geht?

    Ich benutze Python auch nur für kleinere Sachen, weil's schneller geht, z.B. eine CSV-Datei einlesen und ein Histogramm draus berechnen oder sowas. Bin aber nicht so der große Fan von dynamic typing. Ich habe die Typinformation lieber in der Signatur stehen als in Kommentaren, die fehlen können.



  • Blöd an Python finde ich, dass es 2 "aktuelle" Varianten gibt, Python 3 und Python 2.7 (glaube ich). Die Syntax wurde leicht verändert, und Python 3 versteht die alte Syntax nicht mehr. Dumm gemacht. 😞



  • Ich arbeite sehr gern mit Python. Ich finde die Standard-Bibliothek Klasse und nutze es auch für Tools und oder kleinere Programme.

    Dabei stört es mich nicht das ich nicht zwingend im Code feststellen kann um was für einen Daten-Typ es sich handelt, das sollte sich eigentlich aus dem Kontext ergeben wo und wie der Wert genutzt wird. Ohne jetzt über die Code Qualität etwas sagen zu wollen, aber wer Typen während der Laufzeit verändert, dem ist auch nicht zu helfen.

    Aber man kann sich vermutlich in Python schneller reindenken wenn es darum geht etwas zu erfassen, so fern man nicht in einer Zeile 10 Befehle anwendet und noch eine Generator Expression und sowas wie eine anonyme Lambda Funktion... wenn das ein Mensch programmiert hat.
    Wie sagt man ja auch gern "With great freedom comes great responsibility" und so ist es eigentlich auch mit Python aber auch in vielen anderen Sprache auch, man kann viel schlecht als recht (aus)nutzen.

    Und das man wirklich viel out-of-box erledigen kann und es noch tausende von Erweiterungen für diese Sprache gibt, muß man dann noch mehr erklären?

    Auch für Prototyping ist Python sehr gut geeignet. Wenn ich das jetzt zum Beispiel mit C Vergleiche:
    - Ich muss mich nicht um Speicherverwaltung kümmern
    - Ich muss keine Funktionen erfinden weil ich die gängigsten Sache alle in der Standardbibliothek finden kann
    - Ich muss mich nicht um Datentypen kümmern - und hier auch nochmal der Zusatz, wer Datentypen während der Laufzeit verändert, ist selbst schuld...
    - Keine Pointer
    - Ich brauch weniger schreiben, warum Klammern in ein if setzen?
    Okay, ich machs dennoch, der Klarheit halber, aber man braucht es theoretisch nicht.
    - Kein Semikolon am Ende der Zeile - ist Gewöhnung, aber mit oder ohne, es ist kein Fehler
    + Keine Klammern im Kontrollflow, keine geschweiften Klammern für Funktionsblöcke, alles dank der Einrückung die die gängigen Editoren/IDEs unterstützen und berücksichtigen
    Das kann ein Nachteil sein wenn man nicht konkret sehen kann wann und ob man im richtigen "Ident-Level" ist bei vielen Zeilen Code mit einer If-Abfrage, hat aber sonst auch einige Vorteile das der Code simpler und etwas aufgeräumter aussieht (Anti-Spaghetti-Code Verlauf)
    - Nutzbarkeit in anderer Software - ich glaube zum Beispiel Blender hat eine Python-Schnittstelle mit der man arbeiten kann, Gimp auch wenn ich mich nicht komplett irre
    - Kommt mit vielen Datenstrukturen von Haus aus die unterschiedliche Stärken und Schwächen haben

    und vermutlich noch vieles mehr.

    Dazu kommt wie gesagt auch der Vorteil, wenn man mal schnell Texte oder Daten auswerten muß oder mal eben etwas ausplotten lassen will, hat man sehr schnell sehr gute Resultate, und vor allem in wenigen Minuten. Die Sprache ist unter anderem dafür geboren worden bzw. findet man zig Erweiterungen. Und man muß nicht großartig über die Details nachdenken, die Sprache kommt einem entgegen.

    C ist jedenfalls für kleinere Aufgaben overkill meines Empfindens nach und Python ist und bleibt handlich(er) und wie gesagt, für Prototyping ideal.

    Natürlich kann ich das nicht 100% einschätzen weil mir die Erfahrung und viele Kniffe in C fehlen - aber Python ist es da generell freundlicher und viel Einsteigerfreundlicher.

    Man muß es nur auch so nehmen wollen/können und nicht nur darauf verweisen das eine Sprache falsch gebraucht werden kann, das geht mit vielem so sobald einem viele Möglichkeiten und Wege offen stehen und es "verziehen" wird, weil die Sprache Fehlertolerant ist.



  • def greeting(name: str) -> str:
        return 'Hello ' + name
    

    https://www.python.org/dev/peps/pep-0484/

    😃



  • Nun ja, in dem PEP steht aber auch, das es für Linter/Code Checker verwendet werden soll und nicht direkt vom Interpreter als Hinweis gennommen wird wie ein Typ wirklich aktuell definiert ist bzw. beim Aufruf der Funktion in diesem Fall. 🙂

    Oder um den PEP zu zitieren:

    While these annotations are available at runtime through the usual __annotations__ attribute, no type checking happens at runtime . Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily. Essentially, such a type checker acts as a very powerful linter

    Ist allerdings wirklich nicht so geradeaus wie man es sich wünschen würde, auf den ersten Blick jedenfalls, ich würde dann auch erwarten das "name" vom Typ String ist.. und eigentlich sollte der Interpreter das ja dann auch überprüfen und anzeigen wenn dem nicht der Fall ist. Meine ich jedenfalls. *Aber wenn man auf diese Zugreifen und dann selbst Type-Checking betreiben kann, gar nicht so schlecht. 👍

    Das würde zwar wieder viel Rechenpower kosten wenn der Interpreter die Arbeit erledigen würde, aber man könnten Python auch mit einem extra Parameter aufrufen, der die Notationen berücksichtigt und überprüft. 😉

    In jedem Fall aber ganz gut das man sowas nicht als Standard voraussetzt, das würde die Sprache wieder "unnötig" kompliziert mache und gegen das Credo von "Einfachheit" sprechen.



  • Zeus schrieb:

    def greeting(name: str) -> str:
        return 'Hello ' + name
    

    https://www.python.org/dev/peps/pep-0484/

    😃

    Type Annotations sind eines der wenigen Dinge, die selbst innerhalb der Python-Community für Streit sorgen. IMHO ist die Kritik daran durchaus berechtigt.

    Davon abgesehen hat - für mein Empfinden - Python die wenigsten Nachteile, die sonst andere "höhere" Programmiersprachen mit sich führen. Java hat an bestimmten Stellen Performanceprobleme, größere C(++)-Programme will ich nicht ohne längere Einarbeitung in der Sprache schreiben müssen, und PHP merkt man an, dass OOP mehr schlecht als recht draufgepfropft wurde. C# zieht einen ggf. performancefressenden Rattenschwanz an Runtimes hinter sich her, was sich auch nicht überall rentiert. Und Bash? Mir ist mal die Art und Weise, wie unterschiedlich Arrays je nach (angeblich API-stabiler) Version behandelt werden, derbe auf die Füße gefallen (wohl ein Bug der klammheimlich irgendwann mal behoben wurde; ich konnte nichts dazu finden). Seitdem setze ich die Bash als Skriptsprache auch nur noch ein, wenn es nicht anders geht.

    Frei von Fehlern ist Python ganz sicher nicht (eine "richtige" Zwangsdeklarierung von Variablentypen, die man optional zuschalten kann, würde ich mir gelegentlich wirklich wünschen, damit ein Tippfehler wegen eines Variablennamens nicht gleich zu fehlerhaftem Code führt), aber es schlägt schon den einen oder anderen Einsatzbereich, für den ich die Sprache nicht mehr wechseln möchte.

    Manche Probleme sind konzeptionsbedingt und lassen sich ggf. einfach beheben (eine Sprache ohne vorgeschriebene Typdeklaration ist nunmal flexibler; entweder man ignoriert das, oder nutzt es und sorgt selbst für lesbaren Code), andere sind IMHO schon arg merkwürdig (private/public/protected gibts nur indirekt durch vorangestellte Unterstriche beim Variablennamen; triviale Getter/Setter werden auch nicht gern gesehen weil man direkt "von Außen" die Attribute verändern kann; manche Patterns (z.B. Singletons) sind regulär nur mit Tricks möglich. Spätestens bei der Unterscheidung Call-by-Value/-Reference geht Python einen IMHO seltsamen weg, dessen Designentscheidung ich beim besten Willen nicht nachvollziehen kann).

    Auf der anderen Seite habe ich eine reiche Auswahl an Bibliotheken; triviale Skripte lassen sich IMHO kaum eleganter als mit Python lösen. Für Datenbank-Aufgaben will ich nicht mehr auf SQLAlchemy verzichten müssen, ich liebe das Ding^^. Dictionaries gibts zwar auch in anderen Sprachen, aber so flexibel wie hier hab ich sie auch noch in keiner anderen Sprache kennengelernt. Das Erstellen von allein lauffähigen Programmen ist leider komplizierter als es sein müsste, dennoch ist es möglich, als Zielplattform praktisch alle relevanten Plattformen (Win, Lin, Mac, And, iOS) abzudecken. Und so verpönt VisualBasic auch ist, im Prototyping war es mal unschlagbar - bis Python und ein Haufen Librarys das ebenfalls ermöglichte (u.a. Qt, dessen Designer wirklich alles andere als schlecht ist).

    TL, ich weiß^^...



  • triviale Skripte lassen sich IMHO kaum eleganter als mit Python lösen.

    hängt vom Einsatzzweck ab. Perl und awk sind oft auch keine schlechte Wahl für triviale Scripts.

    Beispiel: Bestimme die Hauptdiagonalelemente einer Matrix ohne diejenigen Zeilen, in denen eine Exponentialzahl mit positivem Exponenten vorkommt.

    awk '!/[eE]\+/ { print $NR }' data
    

    Gespannt, ob das in python eleganter geht.



  • Astorek86 (n.A.) schrieb:

    Java hat an bestimmten Stellen Performanceprobleme

    Und Python hast so lustige Sachen wie __getattr__. Python IST ein Performanceproblem 😉


Anmelden zum Antworten