Python-Buch sucht Testleser

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
Antworten
Benutzeravatar
flexit
User
Beiträge: 2
Registriert: Mittwoch 1. April 2020, 20:09

Hallo zusammen,
nachdem bereits mein erster Thread dazu geführt hat, dass ich viele hilfreiche und positive Rückmeldungen erhalten habe, bedanke ich mich bei allen, die sich gemeldet haben, und kann nun das fertige Werk präsentieren. Gesucht werden Testleser, die gegen eine kleine Vergütung (15€ Amazon Gutschein) Interesse an der Lektüre haben und online eine Rezension posten würden.

Klappentext
Wer die Grundlagen von Python beherrscht und jetzt tiefer einsteigen möchte, kommt in diesem Buch auf seine Kosten. Mittels konkreter Anwendungsbeispiele aus verschiedenen Fachgebieten wird aufgezeigt, wie man Python produktiv zur Problemlösung einsetzen kann. Diskutiert werden dabei neben den allgemeinen Lösungsideen auch die Spezifika von Python und wie diese gewinnbringend genutzt werden können. Somit veranschaulicht das Buch allgemeine Konzepte der Programmierung, wie beispielsweise Algorithmen, Rekursion und Datenstrukturen, und lehrt problemorientiertes Denken.
Amazon Beschreibung

Leseprobe (ca. 2,5 MB)

Bei Interesse bitte PM an mich. Da der Druck aktuell noch läuft kann ich Kurzentschlossenen eine digitale Version zusenden, wahlweise als PDF oder EPUB.

Viele Grüße
Bolitho
User
Beiträge: 219
Registriert: Donnerstag 21. Juli 2011, 07:01
Wohnort: Stade / Hamburg
Kontaktdaten:

Schick es mir gerne zu: thomas@daten.coach
Gerne als epub.

Was ich nicht verstehe ist die Ausrichtung auf Menschen, die Grundlagen von Python beherrschen, und dann der Inhalt, der mit Grundlagen beginnt und, nach den Überschriften geurteilt, erst im letzten Kapitel fortgeschrittene Konzepte erklärt.

Das Buch könnte für mich als Begleitung zu Python-Kursen sehr interessant sein. Aber dazu würde ich natürlich entsprechendes Feedback geben.
Benutzeravatar
__blackjack__
User
Beiträge: 13003
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Anmerkungen zur Leseprobe:

S.14 „[…] also alle Dateitypen […]“ → Datentypen

``assert`` ist keine finale Lösung um Nutzereingaben zu kontrollieren ist eine Untertreibung: ``assert`` wird *gar nicht* verwendet um Nutzereingaben zu kontrollieren. Das ist nicht die Aufgabe. Damit testet man ob der Programmierer etwas falsch gemacht hat, also der Code die Zusicherungen, die der Programmierer gemacht hat, (nicht) erfüllt. Mit ``assert`` testet man Dinge die *immer* wahr sind. Da man weiss das der Benutzer auch gerne mal E-Mail-Adressen ohne @ eingibt, ist das nichts was immer wahr ist.

„Ob man nun zum Einrücken Leerzeichen oder Tabulatoren nutzt, ist unerheblich,“

Nope, ist es nicht: Vier Leerzeichen pro Ebene, keine Tabulatoren.

Und auch der Stil bei Namen ist nicht frei wählbar: Namen werden klein_mit_unterstrichen geschrieben. Ausgenommen Konstanten (KOMPLETT_GROSS) und Klassen (MixedCase).

Was mit Korinthen: Die Aussage das ein Bool-Wert keine Zahl ist, stimmt technisch nicht:

Code: Alles auswählen

In [214]: issubclass(bool, int)                                                 
Out[214]: True

In [215]: isinstance(True, int)                                                 
Out[215]: True

In [216]: True * 42                                                             
Out[216]: 42

In [217]: False * 23                                                            
Out[217]: 0

In [218]: True + 1                                                              
Out[218]: 2

In [219]: False - 1                                                             
Out[219]: -1

In [220]: int(True)                                                             
Out[220]: 1

In [221]: int(False)                                                            
Out[221]: 0
„Für kürzere Kommentare in einer Zeile wird das Rautenzeichen verwendet (#).“

Für *alle* Kommentare wird das Rautenzeichen verwendet. Zeichenkettenliterale sind keine Kommentare! Die sind an bestimmten Stellen für Docstrings da, deren Inhalt sich aber von Kommentaren zum Code unterscheiden, weil Kommentare den konkreten Code erklären, Dokumentation in der Regel aber nur die Funktionalität, ohne auf die konkrete Implementierung einzugehen.

Zudem sind literale Strings bei einigen Werkzeugen auch Docstrings an Stellen, die vom Python-Compiler nicht vorgesehen sind. Also kann man in der Praxis auch nicht einfach sagen „Hier gehört kein Doctsring hin, also kann man da auch eine Zeichenkette zum kommentieren verwenden“, weil dieser Kommentar dann am Ende vielleicht doch ungewollt in der Dokumentation landet.

Da PEP8 anscheinend bekannt ist, Frage ich mich warum die Empfehlungen davon teilweise so stark abweichen. Die meisten IDEs und Editoren + Plugins zum Python programmieren prüfen das ja auch mittlerweile und markieren Abweichungen entsprechend.

Das man Module ohne Seiteneffekte importieren können sollte, hätte ich ja auch für sehr praxisrelevant gehalten, weil es dann einfacher ist Code interaktiv zu testen, und so einige Bibliotheken und Werkzeuge für parallele Ausführung, Dokumentation, und automatisierte Tests das erwarten. Das „3_parallelisierung.py”-Modul wird so unter Windows beispielsweise nicht funktionieren.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Antworten