Python richtig lernen, wie?
-
__blackjack__
- User
- Beiträge: 13239
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Fimbur: Nein, nicht wirklich. 
Please call it what it is: copyright infringement, not piracy. Piracy takes place in international waters, and involves one or more of theft, murder, rape and kidnapping. Making an unauthorized copy of a piece of software is not piracy, it is an infringement of a government-granted monopoly.
@narpfel
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
Meinst Du dieses Video?Natürlich nicht. Sockets und SQL sind halt (leider) anscheinend ein guter Lackmustest.
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
@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)
(Bobby Tables)
@narpfel,
https://docs.python.org/3/library/socket.html#example
Oder wie meinst du das?
Gilt das auch für die Python Dokumentation zu sockets?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.
https://docs.python.org/3/library/socket.html#example
Oder wie meinst du das?
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.Buchfink hat geschrieben: ↑Samstag 23. Oktober 2021, 21:03 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".
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.
Wenn man hier "Daumenhochs" vergeben könnte, gäbe ich Dir hundert!
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).
@rogerb: Was genau meinst du? In der Dokumentation zu `socket.send` wird das doch sehr ausführlich beschrieben:
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.
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.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.
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.
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.
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.
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
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
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
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
Ich bin Pazifist und greife niemanden an, auch nicht mit Worten.
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
-
sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
@ThomasL: auf der PyCon 2019 wurde von einem Python-Core-Developer gesagt, dass Python eines der größten (ich meine sogar das größte) Open-Source-Projekt ist, wenn es um die Anzahl der Contributor geht. Ergo hast du zig tausende offener Pull-Requests, aber nur eine vergleichsweise niedrige Anzahl an Maintainer.
Es kann also mitunter sehr frustrierend sein viel Arbeit darein zu stecken und dann einen Pullrequest Jahre-lang vor sich hinschimmeln zu sehen.
Es kann also mitunter sehr frustrierend sein viel Arbeit darein zu stecken und dann einen Pullrequest Jahre-lang vor sich hinschimmeln zu sehen.
When we say computer, we mean the electronic computer.
@ThomasL: Wenn es dich stört, dann schreib doch selber einen PR? Nicolas Dumazet hat doch schon vor über einem Jahrzehnt gezeigt, wie’s geht. Natürlich davon abgesehen, dass das Problem natürlich an mehreren Stellen erwähnt wird, u. A. die Stelle, die ich schon zitiert habe und natürlich im HOWTO:
Now we come to the major stumbling block of sockets - send and recv operate on the network buffers. They do not necessarily handle all the bytes you hand them (or expect from them), because their major focus is handling the network buffers. In general, they return when the associated network buffers have been filled (send) or emptied (recv). They then tell you how many bytes they handled. It is your responsibility to call them again until your message has been completely dealt with.
@narpfel: Es stört mich persönlich nicht, denn ich habe in 3,5 Jahren Python nicht einmal was mit Socketprogrammierung gemacht.
Ich bin also wirklich der letzte der dafür geeignet wäre diese Thematik wo auch immer anzustoßen.
Nur wenn sich die, die sich darin perfekt auskennen, nicht darum kümmern, dann müssen sie sich halt auch nicht darüber wundern,
dass immer wieder der gleiche vermurkste Code hier im Forum gepostet wird und dann die Threadersteller und Python Anfänger "anmachen" das "ihr" Code Scheiße ist.
Sie haben nur den Code ausprobiert den alle anderen im Netz aus der gleichen beschissenen Quelle immer und immer wieder in Tutorials etc rudimentär "erklären".
Just my humble opinion.
Ich bin also wirklich der letzte der dafür geeignet wäre diese Thematik wo auch immer anzustoßen.
Nur wenn sich die, die sich darin perfekt auskennen, nicht darum kümmern, dann müssen sie sich halt auch nicht darüber wundern,
dass immer wieder der gleiche vermurkste Code hier im Forum gepostet wird und dann die Threadersteller und Python Anfänger "anmachen" das "ihr" Code Scheiße ist.
Sie haben nur den Code ausprobiert den alle anderen im Netz aus der gleichen beschissenen Quelle immer und immer wieder in Tutorials etc rudimentär "erklären".
Just my humble opinion.
Ich bin Pazifist und greife niemanden an, auch nicht mit Worten.
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
Das von narpfel gezeigte howto ist eigentlich schon recht gut. Er erwähnt zumindest die wichtigsten Lektionen. Wenn es also dadurch besser würde, dass es richtige Tutorials gibt, dann wäre das denke ich damit getan. Offensichtlich ist es das aber nicht. Weil die Suchmaschinen einem eben sonst etwas vorlegen. Nicht immer die eine Quelle. Und Anfänger das ja nicht als mangelhaft erkennen können.
Bessere Chancen hätte man wahrscheinlich hier, indem man auf die im Kern vielleicht 50 oder so Fragen, die etwa 95% des Aufkommens hier ausmachen, auf gute Antworten, oder ein WIKI oder so, verweist. Allerdings bin ich auch da letztlich skeptisch. Es gibt sicher Leute, die durch sowas weiterkommen. Aber wie oft muss man nach einer Antwort, die “Superspezialbegriff” beinhaltet hat, die Folgefrage erleben: “was ist denn Superspezialbegriff?” Statt das zu suchen, und sich zu erarbeiten. Und da reden wir ja noch gar nicht von denen, die eigentlich gar nicht dahinter steigen wollen, sondern nur ihren Kühlschrank mit einer LED-Leiste verzieren, oder reich mit BTC werden.
Du hast natürlich eine Punkt, dass die Schuld für diesen Zustand nicht notwendigerweise bei dem Neuling liegt, und dem mit kurz angebundenen Worten (bis zur Patzigkeit) nicht geholfen ist. Da die Geduld zu bewahren ist aber leider auch nicht immer meine Stärke. Ich versuche mich da gelegentlich am Riemen zu reißen. Mit mittelmäßigem Erfolg.
Bessere Chancen hätte man wahrscheinlich hier, indem man auf die im Kern vielleicht 50 oder so Fragen, die etwa 95% des Aufkommens hier ausmachen, auf gute Antworten, oder ein WIKI oder so, verweist. Allerdings bin ich auch da letztlich skeptisch. Es gibt sicher Leute, die durch sowas weiterkommen. Aber wie oft muss man nach einer Antwort, die “Superspezialbegriff” beinhaltet hat, die Folgefrage erleben: “was ist denn Superspezialbegriff?” Statt das zu suchen, und sich zu erarbeiten. Und da reden wir ja noch gar nicht von denen, die eigentlich gar nicht dahinter steigen wollen, sondern nur ihren Kühlschrank mit einer LED-Leiste verzieren, oder reich mit BTC werden.
Du hast natürlich eine Punkt, dass die Schuld für diesen Zustand nicht notwendigerweise bei dem Neuling liegt, und dem mit kurz angebundenen Worten (bis zur Patzigkeit) nicht geholfen ist. Da die Geduld zu bewahren ist aber leider auch nicht immer meine Stärke. Ich versuche mich da gelegentlich am Riemen zu reißen. Mit mittelmäßigem Erfolg.
@ThomasL Wer schon weiß wie es geht schaut sich halt solche Tutorials nicht an, dadurch wird sowas auch nicht so schnell auffallen. Da sich dieser Bereich nicht wirklich verändert, ist der Bedarf in die Dokumentation zu schauen auch nicht so hoch, funktioniert ja noch alles wie vor ein paar Jahrzehnten. Letztendlich am wichtigsten wird aber sein, deswegen sind ja auch diese Fehler in den Tutorials drin, kaum jemand nutzt sockets direkt. In der Praxis haben nur ganz wenige Menschen mit Netzwerken auf einer Abstraktionsebene unter HTTP, irgendeinem RPC Protokoll oder Clients für Datenbanken zu tun. Selbst wenn du an verteilten Systemen arbeitest wo es wichtig ist zu wissen wie Netzwerke funktionieren, musst du dich nicht auf so einer niedrigen Abstraktionsebene bewegen. Insofern ist es auch wirklich nicht sinnvoll so ein Thema in Tutorials die Anfängern programmieren beibringen wollen aufzugreifen. Leute die solche Tutorials machen scheinen aber dass Gefühl zu haben sowas muss unbedingt mit drin sein.