Python richtig lernen, wie?

[Buchfink]

@sparrow

Ok, das erschließt sich mir nicht. RAD empfinde ich auch nicht als Müll. Das kann - je nach Anwendungsfall - durchaus Sinn machen.

Hier habe ich meine Worte vielleicht etwas zu hart gewählt.

Aber ich möchte es auch begründen.
1)
In Delphi funktioniert die RAD-Thematik auf den ersten Blick zwar recht gut. Wenn man jedoch komplexere Oberflächen bauen möchte, ist man z.B. mit Vererbung ganz schlecht beraten und auch Aggregation funktioniert eher so lala. Man muss sich vorstellen, dass Delphi dazu Kommentare erzeugt, diese auswertet und per Magie kann man sich dann Oberfächen aus anderen Oberflächen zusammenzimmern.
Wenn ihr jetzt "OMG" denkt, denkt ihr genau richtig
Nach meinem Wissensstand funktioniert das in C# deutlich besser.

2) Ich sehe die RAD-Thematik als weitestgehend gescheitert an. Denn das Versprechen war ja, dass man damit "rapid" Software entwickeln kann. Aber die Wahrheit ist, dass das Erstellen von Oberflächen oft nur einen Bruchteil der eigentlichen Arbeit ausmacht und ich kenne kein einziges Projekt, dass wg. RAD schneller fertig geworden wäre. Man bekommt ggf. ein paar Stunden früher einen Prototypen. Und die eigentliche Arbeit steckt ja oft im Klären von Anforderungen bzw. in irgendwelchen Details, die zu beachten sind.

3) Die RAD-Technik hat zumindest in Delphi dazu geführt, dass die "Hemmschwelle" zum Programmieren drastisch herabgesenkt wurde. Das wiederum hat dazu geführt, dass sehr viele Leute "Oberflächen und Datenbankanbindungen" zusammengeklickt haben und sich anschließend auf Entwicklerstellen beworben haben. Hier muss ich jetzt auf @narpfels Beitrag kommen. Dadurch hat sich leider sehr viel Falschwissen verteilt, dem nicht mehr Herr zu werden ist. (Ich erinnere mich an etliche ehemalige Kollegen, die die Probezeit nicht überstanden haben, da sie das komplette Backend in die Event-Handler gehäkelt haben. Hinzu kam, dass es in diesem Code vor Speicherlecks nur so gewimmelt hat. Solcher Code ist wirklich gefährlich und kann Regressforderungen etc. nach sich ziehen.)

Aber ansonsten beschreibt "C# ist eher Java als C" durchaus korrekt und beschreibt auch meinen ersten (syntaktische) Eindruck, als ich damals C# das erste Mal gesehen habe. Merkwürdig finde ich die Aussage nicht.

Ich bin von C# auf Delphi migriert und muss sagen, dass vieles extrem ähnlich ist. Man fühlt sich in vielen Dingen "sofort zu Hause". Und nach meinem Empfinden auch sehr viel ähnlicher als zu Java. Allerdings ist das eher Bauchgefühl und die Vokabel "seltsam" ist auch in diesem Sinne zu lesen
Mir kam die Aussage eher so vor wie "Eine Blume ist mehr wie ein Fisch": Ja beides sind irgendwie Lebewesen. Aber sonst....hm... (und genau da kommt das seltsame Gefühl ins Spiel)
Aber bei "Gefühlen" ist es ja ohnehin schwer zu argumentieren. Daher bitte einfach wegsortieren.

[Buchfink]

@__blackjack__

-1 ist ja nicht gleich `False`. 0 wäre das. Es ist auch nicht gleich `True`. Aber im boole'schen Kontext wird es dann schon wie `True` behandelt, denn da ist nur die 0 `False`.

Du hast in diesem Punkt völlig Recht. Und in diesem Kontext (viewtopic.php?f=1&t=53114&p=394240#p394240) hatte ich das auch schon "herausgefunden". Dies sei zu meiner Ehrenrettung gesagt
In MS-Access ist -1 aber tatsächlich false, vermutlich ist da in meinen Kopf eine weitere Assoziation (weil ich hin und wieder MS-Access-DBs auswerten muss). Jedenfalls erschien mir die "-1" im gegebenen Kontext irgendwie uneindeutig, da ich mich gefragt habe, auf welcher Skala sie einzusortieren ist.
Und meine Assozionskette war dann einfach "von hinten zu lesen".
Der Kommentar hinter der "-1" war ja so formuliert, dass die Tutorials nicht zu empfehlen sind und ich hab nicht gecheckt, wie das mit -1 in Verbindung steht. Mein Hirn hat wohl folgendes ausgerechnet:
"nicht zu empfehlen" --> (weil) falsch --> false --> -1 --> Widerspruch!?

Ich wollte nur sicher gehen, dass ich @narpfels Beitrag wirklich richtig interpretiere.

Hätte da "5-" gestanden, hätte ich wohl die Assoziation mit Schulnoten gehabt, dann wäre es zumindest "gefühlt" wieder eindeutig gewesen. Aber sei's drum. Die Message von @narpfel ist ja angekommen

Ich denke beim GUIs zusammenklicken war es anders herum: Visual Basic 1 (1991) bis 3 (1993) sind älter als Delphi 1 (1995). Microsoft ist Schuld!

Die Delphi-Gemeinde macht den Abgang von Hejlsberg zu Microsoft dafür verantwortlich, dass es bei Borland, CodeGear und wie sie alle hießen anschließend kaum noch echte Innovation gab. Die RAD-Thematik war wohl auch ein Grund dafür, dass Delphi eine Zeitlang relativ erfolgreich war und dann plötzlich eben nicht mehr. (Es gab noch andere Gründe, die damals eine Rolle spielten auf Delphi zu setzen. Aber ich glaube, das interessiert hier keinen )
Ich bin mir nicht sicher, wie das in Visual Basic 1991 tatsächlich ausgesehen hat und was Borland daraus gemacht hat.
Ich vermute, dass es so in die Richtung geht, wie man sich auch in MS-Access Oberflächen zusammenklicken kann (vielleicht meinst Du das auch)

LG

[__blackjack__]

@Buchfink: Ich denke Delphi war wegen dem Pascal-Erbe erfolgreich, relativ zu Visual Basic beispielsweise, und weil Pascal nativ kompiliert war und Visual Basic in der Regel ”P-Code“, der von der jeweiligen VBRUN*.DLL die man ja immer brauchte, dann interpretiert wurde.

In Visual Basic hat man sich GUIs zusammengeklickt und dann in den Event-Handlern die ganze Logik hinterlegt. Und ich meine die eigenständige Programmiersprache, nicht VBA, das in andere Microsoft-Produkte eingebettet ist.

[Buchfink]

@__blackjack__

In Visual Basic hat man sich GUIs zusammengeklickt und dann in den Event-Handlern die ganze Logik hinterlegt

OMG

Und ja: die Performance des Compilers hatte bei der Entscheidungsfindung wohl eine Rolle gespielt.
Allerdings fiel diese Entscheidung "vor meiner Zeit".
Die historische Betrachtung ist durchaus interessant. Am Montag frage ich mal nach. Das interessiert mich jetzt

LG

[narpfel]

Wobei du echt ganz zufällig das Video "Python Tutorial #52 - Sockets" von Morpheus ausgewählt hast, na klar.

Natürlich nicht. Sockets und SQL sind halt (leider) anscheinend ein guter Lackmustest.

Gerade deswegen ist das ja so gruselig. Das sind bekannte Fehler, nicht irgendwelche obskuren Details, von denen man noch nie was gehört hat.

[Fimbur]

Muss ich verstehen was hier geschrieben wird?

[__blackjack__]

@Fimbur: Nein, nicht wirklich.

[Buchfink]

@narpfel

Natürlich nicht. Sockets und SQL sind halt (leider) anscheinend ein guter Lackmustest.

Meinst Du dieses Video?
https://www.youtube.com/watch?v=RQPznV3 ... kzhYoT-KiB

Oder meinst Du SQL im Kontext Python....? (Da hab ich aber jetzt gar nichts gefunden....)

Interessehalber habe ich mir das Video oben mal angesehen. SQL schreibe ich ja ein bisschen öfter als Python

Also wenn ich es beurteilen müsste, würden mir vielleicht zwei Aspekte auffallen:
- SELECT * FROM ....
ist zwar nicht falsch, aber meine persönliche Erfahrung ist, dass es besser ist auf die konkreten Spalten zu gehen (SELCT SpalteA, SpalteB...). Aber es kann sein, dass das nur für die UseCases gilt, die ich so vor "der Flinte" bekomme.
- Reihenfolge /Sortierung.
Man _kann_ vielleicht (?) heraushören, dass SELECT * automatisch "sortiert". Für die DBMS, die ich so kenne, wäre das falsch. Es sieht zwar oft so aus, als sei es sortiert, aber MS-SQL 2005- 2014 sind da definitiv nicht deterministisch wenn ein ORDER BY fehlt. (Ist mir mal im Rahmen eines automatisierten Tests aufgefallen, der zu nicht-deterministischen Ergebnissen führte. Wenn man das nicht weiß, dann kann ich mir vorstellen, dass man sich da einen Wolf sucht.)
- didaktisch finde ich es ok.

Ich bin mir allerdings nicht sicher, ob das die Sachen sind, die Du gemeint hast oder ob Dir ggf. was ganz anderes aufgefallen sind. Ich fände es interessant, von Dir zu hören, ob ich das korrekt "einsortiert" hab.

LG

[narpfel]

@Buchfink: Das ist bezogen auf die Videos, die ich hier verlinkt habe. Und da geht es um die grundlegendsten Grundlagen: Den Code so zu schreiben, dass er nicht für SQL-Injections anfällig ist. Und Sockets ist darauf bezogen, dass ein `socket.send(b"foo")` nicht zwingend `b"foo"` sendet. Und dass das in zu vielen Tutorials nicht beachtet wird, weil die Leute, die die Tutorials machen, das anscheinend selbst nicht wissen.

(Bobby Tables)

[Buchfink]

@narpfel

danke für die schnelle Antwort.

LG

[rogerb]

@narpfel,

Und Sockets ist darauf bezogen, dass ein `socket.send(b"foo")` nicht zwingend `b"foo"` sendet. Und dass das in zu vielen Tutorials nicht beachtet wird, weil die Leute, die die Tutorials machen, das anscheinend selbst nicht wissen.

Gilt das auch für die Python Dokumentation zu sockets?
https://docs.python.org/3/library/socket.html#example
Oder wie meinst du das?

[LukeNukem]

Im Moment befürchte ich, dass man leider fast in jedem Tutorial irgendwas finden wird, was nicht "rund" ist. Ich denke, wenn man immer schön kritisch bleibt, dann kann man Widersprüche/Fehler/Lücken anderweitig kompensieren. Hoffe ich jedenfalls.

Ein Entwickler muss ja ohnehin eine gewisse Fähigkeit haben, solche Dinge zu erkennen. Es kann ja auch sein, dass man mal eine Spezifikation lesen muss, in der sich Widersprüche/Fehler/Lücken tummeln. Da muss man ja auch jedes Wort auf die Goldwaage legen und "abwiegen".

Das ist der Punkt. Jeder Entwickler kann Scheißcode schreiben können, ohne es zu erkennen, weil die Doku (oder das eigene Verständnis derselben) schlecht war.

Gute Entwickler schmeißen den Müll dann weg und machen ihn besser. Schlechte halten sich die Nase zu und arbeiten um den Geruch herum.

[LukeNukem]

@Fimbur: Nein, nicht wirklich.

Wenn man hier "Daumenhochs" vergeben könnte, gäbe ich Dir hundert!

[LukeNukem]

Oder meinst Du SQL im Kontext Python....? (Da hab ich aber jetzt gar nichts gefunden....)

Interessehalber habe ich mir das Video oben mal angesehen. SQL schreibe ich ja ein bisschen öfter als Python
[...]

Das soll wohl eine SQL-Einführung sein und kein Python-Tutorial, oder?

In Python benutzen wir, wie in anderen dynamischen Skriptsprachen, oft kein SQL, sondern einen objektrelationalen Mapper (ORM). Die Relationen werden dabei auf Klassen und Objekte gemappt. Das hat Vor- und Nachteile, aber für handelsübliche Anwendungsfälle überwiegen die Vorteile deutlich. Es gibt einige wenige Ausnahmen, insbesondere für richtig große Datenbanken -- "richtig groß" so ab, grob gesagt, ein paar Gigabyte -- aber sonst sind derlei ORMs wesentlich komfortabler. Zumal die meisten Datenbanken ja, nunja... mehr als eine Tabelle abbilden, also mehrere Tabellen mit Relationen (Fortgeschrittene wissen, daß eine Tabelle eine Relation ist und daß das Ergebnis eines SELECT ebenfalls... genau).

[narpfel]

@rogerb: Was genau meinst du? In der Dokumentation zu `socket.send` wird das doch sehr ausführlich beschrieben:

Returns the number of bytes sent. Applications are responsible for checking that all data has been sent; if only some of the data was transmitted, the application needs to attempt delivery of the remaining data. For further information on this topic, consult the Socket Programming HOWTO.

Oder meinst du den Beispielcode? Da wurde der Fehler in diesem Issue repariert, wobei dieses `conn.send(data)` anscheinend übersehen wurde. Das `socket.recv()` wurde da anscheinend auch übersehen.

Interessanterweise existiert diese Codezeile unverändert seit 5fdeeea vom 2. Januar 1994 (!) und wurde davor unverändert aus diesem Beispiel übernommen. (1. Juli 1991, „Initial revision“ (!)). Das Problem scheint in Python also gewissermaßen Tradition zu haben.

[Sirius3]

es ist halt ein Unterschied, ob man eine API-Dokumentation hat, oder ob man Anfängern etwas beibringen will.
Bugs lassen sich nicht komplett vermeiden, aber immerhin steht in der Dokumentation das Verhalten korrekt beschrieben.
Bei den 99.99% der Anfängertutorials im Netz (und in den Büchern) fehlt aber genau dieser Satz und dort erwarte ich auch eine genaue Beschreibung, wie man das Problem mit Sockets am besten löst. Wenn es nicht speziell ein Tutorial über Sockets ist, dann reicht der Satz: Sockets sind zu kompliziert, jetzt machen wir mal was tolles mit HTTP und den passenden Bibliotheken.

[Buchfink]

Ich muss gestehen, dass ich hinsichtlich fehlerhafter Tutorials etwas unentschlossen bin.
Denn bei meinem Arbeitgeber hat es dazu geführt, dass man keine einzige Weiterbildung über Firmenkosten zu Wege brachte, denn der Entwicklungsleiter hat immer irgendwo einen Mangel gefunden.
Ich kann das verstehen, wenn eine Schulung 1000€ kostet. Aber die Tutorials auf YouTube kosten nichts. Und einem geschenkten Gaul...
Als Entwickler bleibt dann halt nur, sowas in Eigenregie zu machen, was halt auch nicht unbedingt ideal ist, weil man dann eben nur am WE oder abends was machen kann etc.

Wie dem auch sei - Ich sehe es so: ein didaktisch halbwegs brauchbares Tutorial senkt erst mal die Einstiegs- und damit auch die Entscheidungshürde. Man kommt schnell an einen Punkt, wo man entscheiden kann:
lohnt es sich weiter einzusteigen oder nicht?

Wenn ich mich z.B. entscheiden will, was ich "statt/zusätzlich zu" Delphi mal machen könnte, dann wird der Entscheidungsprozess sehr langwierig, wenn ich mit detailreichen technischen Dokus anfange.

Ich wünschte, dass ich schon früher gewusst hätte, was mit Python so möglich ist. Das hätte mir an einigen Stellen das Leben erleichtert.

LG

[rogerb]

Oder meinst du den Beispielcode?

Ja, den meinte ich. Danke für die Links. Das ist interessant. Wie bist du darauf gekommen, das es da mal einen Bug-Report gab? Das ist ja 10 Jahre her.

[narpfel]

@rogerb: `git blame` und `git log -S "conn.send(data)"`.

[ThomasL]

Ich bin ja jetzt auch schon etwas länger hier im Forum aktiv und lese immer wieder über diese fehlerhaften Socket Codebeispiele, die Anfänger hier posten und über die die Profis sich dann echauffieren. (No pun intended).

Wenn ich dann jetzt lese, dass selbst in der Python Doku seit Jahrzehnten fehlerhafter Code steht, dann frage ich mich warum dies niemand korrigiert.

Also, wie wäre es denn mal, wenn die Profis hier im Forum sich darum kümmern, dass diese Fehler in der Python Doku korrigiert werden und
dort Codebeispiele stehen, die explizit auf die Probleme hinweisen und zeigen wie sie korrekt behandelt werden?

Ich denke das wäre doch nicht nur im Interesse der Supporter hier im Forum sondern der gesamten weltweiten Python Community.
Ich bedanke mich schon mal im Voraus bei denen die sich dafür engagieren.
Danke!
VG Thomas