private-Konvention in Python

[Buchfink]

@__blackjack__
mit "attrs" meinst Du vermutlich das hier?
https://www.attrs.org/en/stable/examples.html

Ich werde mich mal näher mit dem Unterschied zwischen "attrs" und "dataclasses" befassen müssen. Ich habe jetzt nur kurz überflogen.
Das Argument mit der Bolilerplate kann ich vollkommen nachvollziehen und das ist auch das was ich als ästhetisch empfinde. Und dass es Tipparbeit abnimmt, kann ich auch sofort nachvollziehen.

Dass mir gestern spontan kein UseCase eingefallen ist, liegt vermutlich daran, dass ich noch nicht ganz den Einsatzzweck verstanden habe. Manches muss man eben ausprobieren, um es richtig zu verstehen.
Mich würde interessieren, in welchen Konstellationen Du das z.B. üblicherweise so einsetzt? (Sorry, ich fürchte, dass ich damit jetzt den Thread "sprenge" - bitte einfach sagen, dann lagere ich das Thema aus)
Bei pandas war es übrigens umgekehrt. Da sind mir jede Menge UseCases aus meinen Arbeitsalltag eingefallen.

Das mit der Testbarkeit ist ein guter Hinweis. Damit habe ich mich allerdings unter Python noch gar nicht befasst. (In meiner aktuellen Sprache geht das leider nur mit extrem viel Boilerplate. Ich bin schon sehr gespannt wie das unter Python funktioniert)

LG

[Buchfink]

@__blackjack__
ich hab nochmal nachgedacht und ich denke, dass ich nun verstehe, was ich _nicht_ an den DataClasses hinsichtlich Einsatzzweck verstanden habe.

Hier mal ein Erklärungsversuch:
Die Idee auf Objekt-Ebene zu vergleichen, um zu sortieren, ist sehr charmant. Und _exakt_ für diesen UseCase ist mir nicht viel eingefallen. Denn ca. 99% der Daten, die ich sortieren möchte, liegen bereits in einer Datenbank. Diese sortiere ich in der Regel bereits per SQL mit ORDER BY und habe dann in der Regel eine bereits sortiere Liste, die dann z.B. in einer Oberfläche in einem Grid visualisiert werden. Wenn diese dann innerhalb des Grids nochmal umsortiert werden, übernimmt den Vergleich wiederum die Grid-Komponente.
Allerdings scheint es ja noch mehr Dunder-Methoden zu geben, die ich ggf. noch etwas genauer ansehen muss.

LG

[__blackjack__]

@Buchfink: Die übliche Konstellation in der ich das einsetze sind Klassen ganz allgemein. Ich suche da nicht nach Klassen wo ich das einsetzen könnte, sondern es kommt manchmal vor, dass ich es aus irgendwelchen Gründen *nicht* einsetze. Zum Beispiel bei GUI-Klassen wo ja in der Regel in der `__init__()` mehr passieren muss, als einfach nur Attribute zu setzen. Ansonsten ist mir alleine das mir der immer gleiche Code von `__init__()` und `__repr__()` abgenommen wird, ein Grund das fast immer einzusetzen.

Das man die dann auch sortieren kann ist ein netter Nebeneffekt, wobei es dann so etwas wie eine ”natürliche” Reihenfolge geben muss und man die Attribute auch in der Reihenfolge angeben muss, die diese Reihenfolge beim sortieren erzeugt. Wobei auch das bei der Fehlersuche oder in (Unit-)Tests nett sein kann, wenn man eine Sequenz mit Objekten in eine kanonische Reihenfolge bringen kann, ob die nun irgendwie ”natürlich” ist, oder nicht.

Was Tests angeht, unbedingt `pytest` anschauen bevor man blindlings das `unittest` aus der Standardbibliothek verwendet. Das in der Standardbibliothek bietet eine auf XUnit basierende API, die man auch von anderen Sprachen kennt. Das ist aber so ähnlich wie XML und (Mini)DOM. Die Idee die gleiche API für alle möglichen Sprachen zu haben ist nur solange nett, wie man in Python nicht Code schreiben muss der wie Java aussieht. Oder noch schlimmer, denn selbst in Java gibt es Alternativen. Wenn die API ”portierbar” sein soll, muss man sich wohl oder übel auf die kleinste Schnittmenge an Spracheigenschaften beschränken, die alle Sprachen bieten. Wobei `pytest` *auch* mit Unit-Tests klar kommt, die mit der `unittest`-API erstellt wurden. Man muss sich da nicht entscheiden, oder wenn man schon klassische Tests hat, alles wegwerfen und neu schreiben.

Mal das Beispiel aus der `unittest`-Dokumentation:

Code: Alles auswählen

import unittest


class TestStringMethods(unittest.TestCase):
    def test_upper(self):
        self.assertEqual("foo".upper(), "FOO")

    def test_isupper(self):
        self.assertTrue("FOO".isupper())
        self.assertFalse("Foo".isupper())

    def test_split(self):
        s = "hello world"
        self.assertEqual(s.split(), ["hello", "world"])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

Mit `pytest`:

Code: Alles auswählen

import pytest


def test_upper():
    assert "foo".upper() == "FOO"


@pytest.mark.parametrize("text, expected", [("FOO", True), ("Foo", False)])
def test_isupper(text, expected):
    assert text.isupper() == expected


def test_split():
    text = "hello world"
    assert text.split() == ["hello", "world"]
    # check that text.split fails when the separator is not a string
    with pytest.raises(TypeError):
        text.split(2)

Wobei es hier schon einen Unterschied in der Anzahl der Testfälle gibt: `test_isupper()` sind bei der `pytest`-Variante *zwei* Tests die unabhängig voneinander durchgeführt werden. Auch wenn der erste fehlschlägt, wird der zweite noch durchgeführt.

Die `setUp()` und `tearDown()` Varianten von XUnit kann man auch nutzen, aber `pytest` führt dafür auch einen Fixture-Mechanismus ein mit dem man Funktionen per Namen registrieren kann, und die werden dann ausgeführt wenn der registrierte Name in den Argumenten des Tests (oder einer anderen Fixturefunktion) auftauchen. Das Beispiel aus der `unittest`-Doku:

Code: Alles auswählen

import unittest


class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget("The widget")

    def test_default_widget_size(self):
        self.assertEqual(
            self.widget.size(), (50, 50), "incorrect default size"
        )

    def test_widget_resize(self):
        self.widget.resize(100, 150)
        self.assertEqual(
            self.widget.size(), (100, 150), "wrong size after resize"
        )

    def tearDown(self):
        self.widget.dispose()

Kann mit `pytest` so aussehen:

Code: Alles auswählen

import pytest


@pytest.fixture(name="widget")
def create_widget():
    widget = Widget("The widget")
    yield widget
    widget.dispose()


def test_default_widget_size(widget):
    assert widget.size() == (50, 50), "incorrect default size"


def test_widget_resize(widget):
    widget.resize(100, 150)
    assert widget.size == (100, 150), "wrong size after resize"

Ja, dass das über die Argumentnamen geht ist ein bisschen magisch. Quasi „dependency injection“ über Namen statt über Typen. Es hat aber beispielsweise den Vorteil, dass man Fixtures leicht kombinieren kann, denn man kann ja über weitere Argumente mit Namen mehr als ein Fixture anfordern. Das ist IMHO deutlich leichter ”composable” als die `setUp()`/`tearDown()`-Methoden. Spielzeugbeispiel:

Code: Alles auswählen

import pytest


@pytest.fixture(name="paragraph")
def create_paragraph():
    return Paragraph("Lorem ipsum…")


@pytest.fixture(name="document")
def create_document():
    return Document()


@pytest.fixture(name="filled_document")
def create_filled_document(document, paragraph):
    document.add_title("Test-Titel")
    document.body.add(paragraph)
    ...
    return document


def test_document_save(filled_document, tmpdir):
    path = tmpdir / "test.doc"
    filled_document.save(path)
    assert path.exists() and path.is_file()
    content = path.read_text(encoding="utf-8")
    assert "Test-Titel" in content
    ...

Wobei im Test `tmpdir` verwendet wird, was eines der praktischen Fixtures ist, die schon mitgeliefert werden. Da bekommt man pro Test ein leeres temporäres Verzeichnis herein gereicht, das nach dem Test samt Inhalt wieder gelöscht wird.

[Buchfink]

@__blackjack__

vielen lieben Dank für die Mühe und die Hinweise! Ich werde das heute Abend genauer lesen.

[Buchfink]

@__blackjack__

Ansonsten ist mir alleine das mir der immer gleiche Code von `__init__()` und `__repr__()` abgenommen wird, ein Grund das fast immer einzusetzen

Ah, verstehe. Also der umgekehrte Weg sozusagen. Ich hatte das auch kurz in Erwägung gezogen, dann aber im Hinblick auf YAGNI wieder verworfen.
Ich hab mir aber nun __repr__() näher angeschaut und bin zum Ergebnis gekommen, dass ein solcher Standard durchaus Sinn macht. Insbesondere beim Debugging/Logging könnte das nützlich sein.

oder in (Unit-)Tests nett sein kann, wenn man eine Sequenz mit Objekten in eine kanonische Reihenfolge bringen kann, ob die nun irgendwie ”natürlich” ist, oder nicht.

Ja, das stimmt natürlich. Ein nicht-deterministischer Test aufgrund einer Zufallssortierung (z.B. auf Basis der Datenbank) ist nicht nützlich.

Leider schaffe ich es heute nicht mehr, den Code zu sichten. Das mache ich morgen.

[Buchfink]

@__blackjack__

Mit automatisierten Testframeworks habe ich leider bisher nur sehr wenig Erfahrung, da das in Delphi leider sehr umständlich ist und nach fast einhelliger Expertenmeinung nur mittelprächtig funktioniert. Allerdings gibt's ja zum Glück je nach Kreativität des Entwicklers noch andere Möglichkeiten (auch in Delphi) automatisiert zu testen. Man muss dann z.B. Abstriche bei der Testtiefe machen.
Es hat daher einen Moment gedauert, bis ich herausgefunden habe, wie die beiden Varianten Untitest und Pytest anzusteuern sind. (Für pytest musste ich in PyCharm in den Settings den Default TestRunner ändern. Ich hoffe, dass das die korrekte Vorgehensweise ist)

Nun verstehe ich auch, warum Du in pytest einen Vorteil siehst. Das Protokoll ist imho auch übersichtlicher.

Ich konnte zwar erkennen, zu welchem Output die folgende Zeile führt. Und das fand ich sehr charmant, weil es auf den ersten Blick so aussieht, als könnte das für generische datengetriebene Tests einen Vorteil bieten.
Ist meine Annahme korrekt?

Code: Alles auswählen

@pytest.mark.parametrize("text, expected", [("FOO", True), ("Foo", False)])

Den @-"Operator" muss ich mir allerdings noch näher anschauen. Mir ist noch nicht ganz klar, wo der Unterschied zwischen Fixtures und Decorator ist. (Muss ich googeln. Mühsam ernährt sich das Eichhörnchen )

Für das Spielzeug-Beispiel habe noch folgendes importiert, damit es (bei mir) laufähig war:

Code: Alles auswählen

from bokeh.models import Paragraph
from xml.dom.minidom import Document

Das waren Vorschläge von PyCharm. Allerdings habe ich keine Ahnung, ob dies sinnvolle Vorschläge sind. Mein Bauchgefühl sagt: Nein.

Leider bekomme ich ohne diese Importe folgende Fehlermeldung

Code: Alles auswählen

Unresolved reference 'Paragraph'
Unresolved reference 'Document'

Ich vermute aber (unabhängig davon ob der Code läuft oder nicht) muss ich zunächst Fixtures verstehen.

Vielen lieben Dank für Deine wirklich sehr hilfreichen Infos. (Dank Deiner Infos oben habe ich direkt gelernt, wie man in Python automatisierte Tests ansteuert! )

LG

[narpfel]

@Buchfink: Ein Dekorator ist einfach nur ein aufrufbares Objekt, das mit einer Funktion oder Klasse aufgerufen wird:

Code: Alles auswählen

@foo
def bar():
    ...

ist exakt das gleiche wie

Code: Alles auswählen

def bar():
    ...

bar = foo(bar)

Das hat also erstmal nichts mit Fixtures zu tun. Pytest benutzt einfach nur die Dekorator-Syntax, um Fixtures zu registrieren.

[Buchfink]

@narpfel

vielen lieben Dank für die Erläuterung.

Auf den ersten Blick sieht es aus wie ein Funktionszeiger.
Allerdings bin ich mir unsicher, ob das in Python der richtige Begriff ist. Ich muss da aufpassen, dass ich nicht Konzepte blind übertrage, weil eine Mustererkennung in meinem Hirn "anschlägt".
Gerne könnt ihr mich hier korrigieren, falls das eine falsche Annahme ist.

Ich habe die Dekoratoren mal im Rahmen eines Flask-Tutorials gesehen. Da wurde das - wenn ich es richtig in Erinnerung habe - für das Routing eingesetzt.
Allerdings verstehe ich Dinge immer am besten, wenn ich es selbst mal aktiv verwende.

[narpfel]

@Buchfink: In Python gibt es keine Zeiger. Alles, was man an einen Namen binden kann, ist ein Objekt. Z. B. ist `42` ein Objekt vom Typ `int`, `True` ist ein Objekt vom Typ `bool` und nach

Code: Alles auswählen

def bar():
    ...

ist `bar` ein Objekt vom Typ `function`. Bei

Code: Alles auswählen

bar = 42
bar = foo(bar)

würdest du ja auch nicht von einem Int-Zeiger sprechen, warum also „Funktionszeiger“?

[Buchfink]

@narpfel, @__blackjack__
ich habe nun diese Erklärung für Fixtures gefunden:
https://www.tutorialspoint.com/pytest/p ... xtures.htm

Es klingt ein wenig so, als wäre "Fixtures" ein pytest-spezifischer Begriff. Wenn ich mir in google die Trefferliste für "fixtures python " anschaue, sieht das zumindest auf den ersten Blick so aus. Ich bin mir allerdings nicht sicher, ob das wirklich stimmt.

LG

[__deets__]

Fixtures sind ein allgemeiner Begriff für Dinge, die man in Tests gerne vorbereitet hat für den eigentlichen Test. Also zb gemockte Datenbanken oder andere Objekte, mit denen der Code unter Test arbeiten soll.

[Buchfink]

@narpfel

In Python gibt es keine Zeiger

Das meinte ich, als ich schrieb, dass ich evtl. Konzepte aus mir bekannten Sprachen übertrage, die in Python _so_ aber nicht greifen oder anders heißen. Da schlägt einfach manchmal die Mustererkennung im Hirn (falsch) zu.

würdest du ja auch nicht von einem Int-Zeiger sprechen, warum also „Funktionszeiger“?

hm... Ist ein Objekt in Python keine Speicheradresse? Bzw. muss man in Python wissen, was auf Heap und Stack liegt? Oder liegt alles auf dem Heap weil alles Objekte sind? Oder bin ich mit diesen Fragen total auf dem Holzweg?

Entschuldigt vielmals - ich müsste all diese Fragen eigentlich erst googeln, bevor ich diese hier so unqualifiziert hier rein puste. Ich hoffe, ihr seht es mir nach.

[Buchfink]

@__deets__
dankeschön für die Erläuterung.

Bin leider etwas unerfahren, was Testframeworks anbelangt. Ich weiß nur, dass ich ohne automatisierte Tests nicht mehr arbeiten möchte. Wenn das in Python so komfortabel geht, ist das absolut klasse

[narpfel]

@Buchfink: „Speicheradresse“, „Heap“ und „Stack“ sind Begriffe, die Python nicht kennt. Und mit „Python“ meine ich die Sprache, nicht irgendeine Implementierung der Sprache. Ein Objekt in Python-der-Sprache ist ein abstraktes Ding, das man an einen (oder mehrere) Namen binden kann, das Attribute hat und auf dem man Methoden aufrufen kann. Wie das implementiert ist, ist in Python-der-Sprache nicht spezifiziert und damit für den Programmierer in erster (und wahrscheinlich auch zweiter) Näherung nicht wichtig.

Ist ein Objekt in Python keine Speicheradresse? Bzw. muss man in Python wissen, was auf Heap und Stack liegt? Oder liegt alles auf dem Heap weil alles Objekte sind? Oder bin ich mit diesen Fragen total auf dem Holzweg?

Diese Fragen machen deswegen im Kontext von Python-der-Sprache keinen Sinn, weil die Dinge, nach denen du fragst, auf dem Abstraktionsniveau einfach nicht existieren. Analogie: „Wie schwer ist 42?“ (Python-die-Sprache) vs. „Wie schwer sind diese 42 Steine, die hier vor mir liegen?“ (Konkrete Implementierung von Python-der-Sprache).

[Buchfink]

@narpfel
dankeschön für Deine hilfreichen Erläuterungen.

Python ist für mich ein bisschen wie "eine andere Welt" Aber es ist eine tolle Welt!

[__blackjack__]

@Buchfink: Wie man das jetzt speziell in PyCharm verwendet weiss ich nicht. Ich schreibe mit einem normalen Editor und lasse Tests im Terminal laufen. Also `pytest` als Programm ausführen, mit dem was getestet werden soll als Argument und ggf. noch Optionen um Tests auf bestimmte einzelne Tests oder Gruppen von Tests einzuschränken, und beispielsweise so etwas wie Doctests auch gleich auszuführen.

Für `unittest`-Tests verwende ich auch `pytest`, weil das wie gesagt auch damit klar kommt, und sofern sich bei `unittest` da nichts geändert hat, sind die Ausgaben von `pytest` um einiges besser, weil das einiges an Mühe darauf verwendet auch den jeweiligen Ausdruck zu verstehen der fehlgeschlagen ist, und welche Werte die beteiligen Variablen hatten, und dann auch versucht ein sinnvolles ”diff” zwischen dem Ergebnis und dem erwarteten Wert anzuzeigen.

Die Klassen `Document` und `Paragraph` sind keine konkreten, das war nur als Beispiel um da irgendwas zu haben, unter dem man sich was vorstellen kann.

Zu „test fixture“ allgemein gibt es eine Wikipedia-Seite: https://en.wikipedia.org/wiki/Test_fixture

Das ist sogar so allgemein, dass der Begriff nicht auf Software-Entwicklung beschränkt ist.

[Buchfink]

@__blackjack__
Ich nutze je nach dem an welchem Rechner ich bin und was gerade zweckdienlich ist, JupyterNotebooks /JupyterLab , PyCharm oder VSCode.
So lerne ich auch gleich die verschiedenen IDEs und deren Vor- und Nachteile.
Im Moment bin ich noch unentschlossen, was mir besser gefällt - aber PyCharm nutze ich deutlich öfter. (Es ist ja alles besser wie das, was von Embarcadero kommt...)

Die JupyterNotebooks finde ich deshalb sehr praktisch, weil man damit auch schnell mal was ausprobieren kann. Es gibt noch eine Reihe weitere Vorteile, die kennst Du aber bestimmt alle. (Manchmal wenn es die Zeit zulässt, versuche ich Probleme, die hier diskutiert werden, zu verstehen und die Lösung nachzuvollziehen. Dabei lerne ich auch ziemlich viel, habe ich festgestellt. Besonders wenn hier verschiedene Lösungen gegeneinander abgewogen werden, finde ich die Diskussion sehr spannend und lehrreich. Dies soll an dieser Stelle auch mal gesagt sein)

und dann auch versucht ein sinnvolles ”diff” zwischen dem Ergebnis und dem erwarteten Wert anzuzeigen.

ja, genau das war mir auch aufgefallen. Und gute Fehlermeldungen sind oft Gold wert.
(Z.B. bei den integrierten automatisierten Tests von Postman sind die Fehlermeldungen imho auch ziemlich gut, aber das nur am Rande.)

Die Klassen `Document` und `Paragraph` sind keine konkreten, das war nur als Beispiel um da irgendwas zu haben, unter dem man sich was vorstellen kann.

ja, das habe ich gestern Abend dann auch irgendwann vermutet. In geistiger Umnachtung habe ich da gestern wohl einigen Stuß geschrieben
Und vielen Dank für den Wikipedia-Artikel. Der war sehr aufschlussreich.

Nachtrag zu meinem Geschreibsel von gestern:
Leider habe ich oft nur am Wochenende länger Zeit, um mich neuen Themen ausführlicher zu widmen. Da sich aber viele nette Menschen hier so viel Mühe geben, mir auch zeitnah Sachen zu erklären, möchte ich immer aber wenigstens kurz darlegen, wie mein "aktueller Wissensstand" dazu ist und wo noch Fragen in meinem Hirn herumschwirren. Denn meist ist das eine regelrechte Fragenkasskade, die dann auf Basis des neuen Inputs in meinem Kopf entsteht.
Und ich möchte keinesfalls den Eindruck erwecken, dass ich die Informationen, die ihr mir hier so freundlich zukommen lasst "versacken" lasse.
Dies nur als kleine Erklärung, warum ich manchmal unqualifizierte Fragen schreibe und direkt dazu schreibe, dass ich das noch googeln muss.
Ich habe den Anspruch, meine Fragen immer so zu formulieren, dass ich nicht "die Entwickler-Innung blamiere" - aber ich glaube manchmal geht das daneben

Morgen ist Samstag. Ganz viel Zeit um mich nochmal ausführlicher mit den ganzen "Dunder"-Methoden zu befassen. Jedenfalls ist das mein Vorhaben für dieses Wochenende.
Dann kommen hoffentlich auch qualifizierte/interessante Fragen von mir.

LG

[Buchfink]

Hallo zusammen,

bei meinen Recherchen bin ich auf folgenden Link gestoßen:
https://nbviewer.org/github/rasbt/pytho ... vate_class

Ich dachte ggf. wäre es sinnvoller, das "Pferd mal von hinten aufzuzäumen" und zu schauen, was es alles sonst so an populären Irrtümern in Python gibt (bevor ich in die nächste Falle latsche)
Sprich: "Wissensdefault" einfach rumdrehen und mal einen Blick auf die Besonderheiten werfen.

Passend zu diesem Thread habe ich die oben stehende Erklärung gefunden. So wie ich das nun mit den Underscores verstanden habe, ist die Erklärung dort nicht falsch. Aber durchaus nicht ganz so klar, wie das, was ich aus dem Beitrag von @__blackjack__ herausgelesen habe. Denn das klingt bei Herrn Raschke so, als wäre das durchaus eine gängige Methode "ein bisschen Privatheit" zu bekommen. Der "Missbrauchscharakter" kommt da imho nicht so ganz heraus.

Was ist denn Eure fachliche Meinung zu dem Artikel über "private"?

Lieben Dank schon mal für Eure Einschätzung.

Hintergrund meiner Frage ist, dass ich nur bedingt einschätzen kann, inwieweit der Rest dort fundiert ist. Einerseits geht es stellenweise sehr in die Tiefe (was ich sehr interessant finde) aber andererseits wird viel Wissen vorausgesetzt (was ich noch nicht habe).
Es werden dort halt viele Fragen beantwortet, die ich mir auch schon gestellt habe.
Im Moment ist die "Private"-Thematik für mich daher bisschen ein Lackmus-Test, um zu entscheiden, ob ich eine Quelle näher ansehe.

Am Rande
Die restlichen Sachen, die dort aufgeführt sind, habe ich nur grob überflogen. Einiges konnte ich verstehen, jedoch nicht alles. Ich habe noch viel vor mir

Sorry wenn der Eindruck entsteht, dass ich mich da ein bisschen "dran festbeiße", aber mir liegt es daran, wirklich zu verstehen, was ich tue. Alles andere ist ja immer "gefährliches Halbwissen".

LG

[/me]

Was ist denn Eure fachliche Meinung zu dem Artikel über "private"?

Klingt prinzipiell OK. Ich würde allerdings den Begriff "private" durch "for internal use" ersetzen.

Da kommt dann der Unterchied zu einem "private" wie es z.B. in C++ verwendet wird zum Vorschein. Ich kann so ein Attribut/eine Methode als Entwickler verwenden, wenn ich davon überzeugt bin, dass mir das Vorteile welcher Art auch immer bringt - und das kann ab und zu tatsächlich sehr praktisch sein. Ich muss mir nur darüber im Klaren sein, dass es keine Garantie dafür gibt, dass besagtes Attribut/Methode in der nächsten Version der Bibliothek noch vorhanden ist und/oder das gleiche tut.

[rogerb]

@Buchfink,

ich weiß nicht ob ich mir anmaßen kann eine fachlich versierte Einschätzung zu geben.
Es ist gut, dass der Autor nicht versucht, public und private auf Python anzuwenden, sondern eigentlich erklärt, dass es diese Zugriffsbeschränkung in Python eigentlich gar nicht gibt. Noch besser wäre es gewesen, den Artikel zu public / private gar nicht zu schreiben
Es ist einfach kein Thema in Python. Ich persönlich habe es auch nie vermisst, seit dem ich in Python programmiere. Das ist so als würdest du mit einem Elektroauto an einer Tankstelle vorbeifahren.

Ich habe den Rest nur überflogen. Es sind sicher einige gute und für Python wichtige und relevante Themen dabei. Erfrischend finde ich, dass es nicht mit "Hallo Welt" anfängt, sondern an eher erfahrene Programmierer gerichtet ist.
Persönlich würde ich offizielle Python-Veröffentlichungen immer als Maßstab nehmen, also das Python Tutorial und die Dokumentation. Dazu kann man noch einen Blick in die PEP werfen um weitere Hintergrundinformationen zu bekommen.
Ich weiß es nicht genau, aber ich bin mir ziemlich sicher, dass diese Dokumente von sehr erfahrenen Python-Entwicklern geprüft bzw. geschrieben werden.
Alles andere ist oft aus der Sichtweise von Einzelnen geschrieben. Dann schaust du halt durch deren Brille.