An alle Schüler und Studenten mit Informatikproblemen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
nezzcarth
User
Beiträge: 540
Registriert: Samstag 16. April 2011, 12:47

Montag 14. Mai 2018, 18:46

RIN67630 hat geschrieben:
Sonntag 13. Mai 2018, 03:35
Dafür ist aber Python denkbar ungeignet!
Ich finde es interessant, dass du das so siehst, denn Python ist, soweit ich weiß, ja ursprünglich als Lehrsprache gedacht gewesen, bzw.aus einer solche Sprache (ABC) hervorgegangen. Das muss jetzt zugegebenermaßen nicht heißen, dass dieses Ziel erfüllt wurde -- viele Menschen scheinen das aber schon so zu sehen. Was schon stimmt, ist, dass Python einige Dinge anders macht, als "traditionellere" Sprachen; und wenn man über viele Jahre hinweg eine bestimmte Art zu Programmieren praktiziert hat, fällt es vielleicht schwer, sich auf Python einzulassen, oder anzuerkennen, dass es anders auch geht (oder vielleicht sogar besser). Mich würde zum Beispiel (ernst gemeinte Frage) interessieren, ob du Pascal für eine bessere Lehrsprache als Python hältst; das könnte aufschlussreich sein.
Benutzeravatar
kbr
User
Beiträge: 914
Registriert: Mittwoch 15. Oktober 2008, 09:27

Montag 14. Mai 2018, 23:06

RIN67630 hat geschrieben:
Montag 14. Mai 2018, 16:06
Dass Python die Daten ohne Deklaration nutzt und gar im Programmablauf verändert, macht es unglaublich schwer den Ablauf zu verstehen, da man nicht vom Code aus wissen kann, welche Struktur die Variable gerade vorweist.
Damit haben viele Probleme, die neu zu einer dynamischen Programmiersprache hinkommen; die vielen Vorteile erschließen sich zumeist langsam – und für manche sogar gar nicht. Anhand Deiner Beschreibung wage ich zu behaupten, dass das Problem nicht bei Python liegt, sondern sich vielmehr im Designentwurf des von Dir zu erweiternden Programms befindet.
Benutzeravatar
snafu
User
Beiträge: 5494
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Dienstag 15. Mai 2018, 06:14

RIN67630 hat geschrieben:
Montag 14. Mai 2018, 12:08
Selbst der Datentyp einer Variable ist nicht stabil.
Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.
Ja, irgendwann kracht es wenn ein falscher Typ vorliegt. Das hast du selbst bei der Standardbibliothek von Python, dass da *nicht* alles Duck-Typing-gerecht programmiert ist und stattdessen ein bestimmter Datentyp verlangt wird. Das ist unsauber, weil inkonsequent, stellt jedoch kein riesiges Problem dar.

Falls dir Typchecks sehr wichtig sind, dann könntest du dir mal das typing-Modul anschauen. Einige Anwendungsbeispiele und wie das ganze dann in der Praxis mit einem Type-Checker aussehen kann, findest du hier:
https://medium.com/@ageitgey/learn-how- ... c86d72677b

Ich würde das bei Python aber nur empfehlen, wenn mit fremden APIs kommuniziert werden muss und diese statische Typen verlangen. Man hat dann den Vorteil, dass es noch auf Python-Ebene kracht, falls kein korrekter Typ vorliegt. Und das würde ich dann auch als gesondertes Modul auslagern. Allgemein sollte man nicht dazu übergehen, alle seine Python-Programme so zu schreiben, denn dann arbeitet man gegen ein fundamentales Konzept der Sprache an.
shcol (Repo | Doc | PyPi)
Sirius3
User
Beiträge: 8270
Registriert: Sonntag 21. Oktober 2012, 17:20

Dienstag 15. Mai 2018, 07:22

RIN67630 hat geschrieben:
Montag 14. Mai 2018, 12:08
Selbst der Datentyp einer Variable ist nicht stabil.
Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.
Die Aussage ist ja falsch. Jede Variable hat einen stabilen Datentyp (Python ist stark typisiert). Es kann einem also nicht wie bei PHP oder Javascript passieren, dass man plötzlich eine Zahl hat, obwohl man einen String erwartet. Was Du meinst, ist, dass nicht der Compiler sofort meckert, wenn irgendeine Vorgabe, die ein Programmierer für nötig befunden hatte, nicht eingehalten wurde. Wenn man aber nur nach Compilermeldungen programmiert, hat man zwar ein formal korrektes Programm, das aber trotzdem voller Bugs ist. Das richtige vorgehen ist so oder so, Funktionen zu schreiben, die per (Unit-)Test auf Korrektheit geprüft sind und daraus ein komplexeres Programm zusammenzusetzen. Dann ist es auch egal, ob oder wie typisiert wird, denn die gefährlichen Fehler sind nicht Typfehler sondern logische Fehler, die kein Compiler erkennen kann. Daher sind die ganzen Typangaben, die jetzt immer häufiger in Pythonprogrammen auftauchen, nur unnützer Balast, der das Lesen und Schreiben verkompliziert, ohne in realen Szenarien irgendeinen Nutzen zu haben.
DasIch
User
Beiträge: 2462
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Dienstag 15. Mai 2018, 08:34

Sirius3 hat geschrieben:
Dienstag 15. Mai 2018, 07:22
Dann ist es auch egal, ob oder wie typisiert wird, denn die gefährlichen Fehler sind nicht Typfehler sondern logische Fehler, die kein Compiler erkennen kann. Daher sind die ganzen Typangaben, die jetzt immer häufiger in Pythonprogrammen auftauchen, nur unnützer Balast, der das Lesen und Schreiben verkompliziert, ohne in realen Szenarien irgendeinen Nutzen zu haben.
Die Typangaben die man in Python jetzt haben kann oder die es in C, Java o.ä. Sprachen gibt sind größtenteils unnütz. Grundsätzlich erlauben dir aber Typsysteme eine ganze Reihe von Fehlern auszuschliessen, was dir erlaubt dich wirklich aufs wesentliche zu konzentrieren. Außerdem erlauben dir Typsysteme Dinge zu tun die sonst gar nicht möglich wären, z.b. erlaubt dir Rust durch Substructural Typing Programme zu schreiben die schnell, sparsam, fehlerfrei und sicher mit Memory umgehen, etwas dass du sobald Concurrency hinzukommt mit einem GC nicht hinbekommst.
__deets__
User
Beiträge: 3300
Registriert: Mittwoch 14. Oktober 2015, 14:29

Dienstag 15. Mai 2018, 10:27

Meiner Meinung nach kommen wir zu einer Art Annaeherung der verschiedenen Ansaetze: dynamisch typisierte Sprachen wie Python versuchen sich die Vorteile von Typen zu eigen zu machen, und statisch typisierte Sprachen erweitern ihre Typsysteme in einer Art, dass die Benutzung einfacher und der Code generischer wird. Dinge wie concept-based polymorphy in C++ sind nix anderes als das gute alte Duck-Typing, aber schon zur compile-zeit angewandt. Ob das zum Erfolg fuehrt, wenn die Sprache nicht mit solchen Typsystemen von Beginn an entworfen wurden, ist sicherlich fraglich. Da bin ich durchaus skeptisch. Sprachen wie Rust oder Kotlin, die von vorneherein mit solchen Typsystemen entworfen werden, haben da ggf. die Nase vorn. So sei es dann halt.

Der praktischen und theoretischen (im Sinne von Wissensvermittlung) Nuetzlichkeit von Python hier und heute in Abrede zu stellen ist davon aber unabhaengig, und schlicht falsch. Aber das aus einem "es gefaellt mir nicht" ein "das ist grundsaetzlich nicht geeignet" wird, ist ja nun nix neues. Wie sollen die Kinder von heute denn gutes rumschleppen lernen, wenn ihnen das Rad die Arbeit abnimmt?
Sirius3
User
Beiträge: 8270
Registriert: Sonntag 21. Oktober 2012, 17:20

Dienstag 15. Mai 2018, 10:52

@DasIch: das ist dann mehr eine Frage der Implementierung. Moderne JIT-Compiler übersetzen Dir ja das dynamische Typing in ein statisches und können auch die Lebenszeit von Objekten genauer bestimmen, so dass ein GC an diesen Stellen gar nicht nötig ist (solange man keine Ringstrukturen hat, kommt ja CPython auch ohne GC aus und macht alles über Reference-Counting).
An ein paar Stellen ist Python auch zu dynamisch. Wäre der globale Namespace WORM, könnte man viele Optimierungen zur Compilezeit machen, ohne wesentliche Einschränkungen bei den Programmen zu haben (globale Variablen dieser Art gäbe es dann nicht mehr, was ein zusätzlicher Vorteil wäre)
RIN67630
User
Beiträge: 26
Registriert: Sonntag 29. April 2018, 08:07

Dienstag 15. Mai 2018, 13:07

snafu hat geschrieben:
Dienstag 15. Mai 2018, 06:14
Falls dir Typchecks sehr wichtig sind, dann könntest du dir mal das typing-Modul anschauen. Einige Anwendungsbeispiele und wie das ganze dann in der Praxis mit einem Type-Checker aussehen kann, findest du hier:
https://medium.com/@ageitgey/learn-how- ... c86d72677b
Ich würde das bei Python aber nur empfehlen, wenn mit fremden APIs kommuniziert werden muss und diese statische Typen verlangen.
Das ist ja gerade mein Pech: dass ich ein fremd geschriebenes Python code, das mit allgemeine APIs kommuniziert, aber ein undokumentiertes Protokoll nutzt, erweitern will.
In so einer Situation, is es kaum möglich vom code aus, auf die Einzelheiten des Protokolls zurückzuschließen. Es ist mit dem knappen Python code beinahe unmöglich herauszufinden, was in welche Variable erwartet wird.
Hätte der Programmierer noch mindestens Kommentare hinterlassen! Das wird zu oft vernachlässigt.
Hier komme ich wieder zu meiner Mantra:
Kommentieren was man macht ist gut, dokumentieren warum man das gerade so gemacht hat ist viel besser.
Sirius3
User
Beiträge: 8270
Registriert: Sonntag 21. Oktober 2012, 17:20

Dienstag 15. Mai 2018, 13:20

@RIN67630: was Du hier aber brauchst, ist einfach eine API-Dokumentation. Solang Du nicht weißt, was eine Funktion macht, hilft Dir halt auch nicht viel weiter, wenn Du weißt, dass da jetzt ein String erwartet wird.
RIN67630
User
Beiträge: 26
Registriert: Sonntag 29. April 2018, 08:07

Dienstag 15. Mai 2018, 17:08

Sirius3 hat geschrieben:
Dienstag 15. Mai 2018, 13:20
@RIN67630: was Du hier aber brauchst, ist einfach eine API-Dokumentation. Solang Du nicht weißt, was eine Funktion macht, hilft Dir halt auch nicht viel weiter, wenn Du weißt, dass da jetzt ein String erwartet wird.
Die gibbet es nicht öffentlich. Aber ich habe angefangen, den Spieß umzudrehen und vorerst ein Datalogger zu schreiben.
Anscheinend haben auch anderen das Problem, so dass Scapy entwickelt wurde.
Kennt jemand die Software?
https://scapy.readthedocs.io/en/latest/
Ist wiederum ein völlig neues Konzept zu lernen...
Antworten