Verständnisfrage: Private Attribute bei Klassen

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.
Antworten
Benutzeravatar
Schwarzer Wolf
User
Beiträge: 56
Registriert: Donnerstag 5. Januar 2017, 05:24

Ich Grüße Euch

Ich habe eine Verständnisfrage zu privaten Attributen:

Kann man Sie gleich schreiben z.B.:

Code: Alles auswählen

self.__variable = variable
oder ist es besser andere Bezeichner zu nehmen:

Code: Alles auswählen

self.__var_x = variable
Wird leider in meinem Haupt Lehrbuch nicht weiter erklärt.
Wer in der Wildnis lebt, muss zum Wolf werden, oder als Schaf sterben.
(Syrisches Sprichwort)
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@Schwarzer Wolf: wenn Dein Hauptlehrbuch von privaten Attributen spricht, dann taugt es sowieso nicht zum Lernen. Es gibt keine privaten Attribute in Python. Wahrscheinlich wurden auch noch weitere Konzepte aus anderen OOP-Sprachen kopiert, die so in Python nicht üblich sind.

Zur Frage: Python kennt viele Namensräume. In jedem Namensraum sind Variablen mit gleichem Namen unabhängig voneinander. Die Variable mit dem Namen "variable" im lokalen Namensraum hat also nichts mit dem Namen "variable" im Namensraum von self zu tun und erst recht nicht mit dem Namen "__variable". Soweit zum Können. Jetzt zum Sollen: Wenn "variable" ein guter Name wäre, der also leicht verständlich sagt, für was die Variable da ist, dann ist "self.variable", bzw. falls das Attribut wirklich nur für intern gedacht ist "self._variable" meist auch ein guter Name.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Ich habe so eine Regel: Alles ist solange read-only bis die Doku das Gegenteil behauptet. Meistens gibt es auch keinen Grund, an den Attributen fremder Klassen herum zu fummeln. Es muss IMHO auch nicht alles, was der Anwender rein theoretisch tun könnte, explizit durch Code verboten werden. Ich würde mich da nur auf naheliegende Fehler beschränken bei den Prüfungen.
Benutzeravatar
Schwarzer Wolf
User
Beiträge: 56
Registriert: Donnerstag 5. Januar 2017, 05:24

@Sirius3

Dann kann ich in der Regel also einfach self.variable benutzen? Von self.__variable ist also abzuraten?

Der Autor meinte, dass öffentliche Attribute eben nicht gern gesehen sind und überschrieben werden können.

Im Python Tutorial 3.3. in Deutsch habe ich jetzt mal nachgesehen und es steht quasi das Gegenteil:
Beachte, dass die Ersetzungsregeln vor allem dazu gedacht sind, Unfälle zu vermeiden; es ist immernoch möglich auf einen solchen als privat gekennzeichneten Namen von aussen zuzugreifen und ihn auch zu verändern. Das kann in manchen Umständen sogar nützlich sein, beispielsweise in einem Debugger.
Dann geht es also in der Regel nur darum, Namenskonflikte in Unterklassen zu vermeiden?

Ja das Hauptlehrbuch hat etliche Probleme und Fehler. Ich bin schon mit der Lektorin im Kontakt bezüglich Beschwerde und anderes. Mal sehen, was bei rauskommt.


@snafu

Kannst Du mir das mit "read-only" genauer erklären. Verstehe das nicht. Sorry
Wer in der Wildnis lebt, muss zum Wolf werden, oder als Schaf sterben.
(Syrisches Sprichwort)
BlackJack

@Schwarzer Wolf: Ja, in der Regel kann man einfach ``self.variable`` verwenden. Die Gefahr von Namenskonflikten ist auch nicht gross, denn die besteht eher bei tiefen Vererbungshierachien oder Mehrfachvererbung die über einfache Mixin-Klassen hinausgehen. Beides kommt in der Praxis in Python kaum vor.

Das deutschsprachige Python 3.3 Tutorial ist eine Übersetzung des offiziellen Tutorials aus der Python-Dokumentation. Inhaltlich ist das also schon so offiziell das, von Übersetzungsfehlern abgesehen, die Aussagen darin von den Python-Entwicklern stammen. :-)

Der Begriff private Attribute dürfte vor allem deswegen in der Dokumentation vorkommen, damit die Leute die ``private`` & Co als Zugriffsschutz aus anderen Sprachen kennen, diese Stelle finden und richtig verstehen.

Bezüglich snafu's „read only“-Policy: Solange ein Attribut nicht ausdrücklich als *nicht* „read only“ dokumentiert ist, ist man auf der sicheren Seite wenn man es als „read only“ betrachtet. Nur wenn die Dokumentation sagt, man kann da auch etwas zuweisen, explizit oder in Code-Beispielen, kann man sicher sein, dass dem auch so ist.

Das öffentliche Attribute nicht gern gesehen sind, würde ich für Python nicht unterschreiben. Zudem kann man, wenn es allein ums *können* geht, auch nicht-öffentliche Attribute problemlos verändern oder neu zuweisen. Eben weil es keinen Zugriffsschutz á la ``private`` gibt.
Benutzeravatar
Schwarzer Wolf
User
Beiträge: 56
Registriert: Donnerstag 5. Januar 2017, 05:24

@BlackJack

Danke für die schnelle Antwort. Nun hab ich das verstanden.

@ all

Danke für die Hilfe

:D
Wer in der Wildnis lebt, muss zum Wolf werden, oder als Schaf sterben.
(Syrisches Sprichwort)
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Schwarzer Wolf hat geschrieben:@snafu

Kannst Du mir das mit "read-only" genauer erklären. Verstehe das nicht. Sorry
BlackJack hatte schon gut erklärt, was ich meinte. Übrigens verbietet mir diese Sichtweise nicht das Definieren von "privaten" Klassen oder Methoden. Es gibt ja häufig Situationen, wo man Hilfskonstrukte benötigt, um bestimmte Abläufe zu vereinfachen, z.B. um sehr ähnliche Codeteile nicht doppelt schreiben zu müssen. Diese "Krücken" sind dann zwar im Kontext der Implementierung sinnvoll, für eine öffentliche Schnittstelle aber nicht so toll (oft sind sie auf einer niedrigen Abstraktionsebene angesiedelt, ihre Verwendung erfordert Kenntnisse über Implementierungsdetails, usw). Die kennzeichne ich natürlich schon mit vorangestelltem Unterstrich, damit der Anwender leicht erkennen kann, dass etwas nur für den internen Gebrauch gedacht ist. Ich finde bloß die übermäßige Einteilung in private Bereiche nervig - allein schon, weil man beim Programmieren dann ständig überlegen muss, ob man etwas jetzt mit oder ohne Unterstrich benannt hat.
Benutzeravatar
Schwarzer Wolf
User
Beiträge: 56
Registriert: Donnerstag 5. Januar 2017, 05:24

snafu hat geschrieben: Es gibt ja häufig Situationen, wo man Hilfskonstrukte benötigt, um bestimmte Abläufe zu vereinfachen
Du meinst damit Klassen, die dem "struct" bei "C" ähneln?

@ all
Mir ist gestern noch eine Frage zu all dem eingefallen:
Es ist dann quasi auch sinnlos, wie in meinem Buch steht "Private Attribute" über get.x oder set.x aufzurufen?
Wer in der Wildnis lebt, muss zum Wolf werden, oder als Schaf sterben.
(Syrisches Sprichwort)
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@Schwarzer Wolf: nein, Konstrukte meint allgemein die Art, wie ich ein Problem löse, hat nichts mit "struct" zu tun. Wenn es für ein Attribut eine Methode gibt, die get_x heißt, dann ist das Attribut ja nicht mehr privat. In Java gibt es den übermäßigen Gebrauch von Boilerplatecode nur, weil es so eine primitive Sprache ist. Triviale Getter und Setter in Python sind unnötig, weil für nicht triviale es Properties gibt.
Benutzeravatar
Kebap
User
Beiträge: 686
Registriert: Dienstag 15. November 2011, 14:20
Wohnort: Dortmund

Schwarzer Wolf hat geschrieben: Es ist dann quasi auch sinnlos, wie in meinem Buch steht "Private Attribute" über get.x oder set.x aufzurufen?
Dein Buch scheint eher mittelmäßig. Welches ist es zufällig genau?

Die beschriebenen Konzepte treffen auf andere Sprachen zu, aber bei Python eher unüblich / unnötig. Daher scheint der Autor eher aus anderen Sprachen auf Python zu projizieren, anstatt wirklich Python zu lehren.
MorgenGrauen: 1 Welt, 8 Rassen, 13 Gilden, >250 Abenteuer, >5000 Waffen & Rüstungen,
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Leider werden Bücher über Programmiersprachen anscheinend nicht zwingend von Experten einer bestimmten Sprache geschrieben, sondern desöfteren auch von Autoren, die sich ganz allgemein für gute Programmierer halten und sich vermutlich ein bißchen was dazuverdienen möchten...
Benutzeravatar
Schwarzer Wolf
User
Beiträge: 56
Registriert: Donnerstag 5. Januar 2017, 05:24

Kebap hat geschrieben:
Dein Buch scheint eher mittelmäßig. Welches ist es zufällig genau?

Die beschriebenen Konzepte treffen auf andere Sprachen zu, aber bei Python eher unüblich / unnötig. Daher scheint der Autor eher aus anderen Sprachen auf Python zu projizieren, anstatt wirklich Python zu lehren.
Python 3 - Lernen und professionell anwenden von Michael Weigend

Ich stehe wie gesagt schon mit der Lektorin in Kontakt, da einige sehr grobe Fehler drin sind. Und Michael wollte sich diese Woche äußern.
An sich ist etliches Gut im Buch. Aber einiges ist sehr im Argen, und dass bei der 6. Auflage. An seinem Code orientiere ich mich nur zum minimal, alleine schon, weil er viele Dinge ein wenig seltsam macht und sich nicht an PEP 8 hält.

Bin wirklich mal auf die Antwort gespannt. Das wird sich dann auf meine Rezension auswirken.
Wer in der Wildnis lebt, muss zum Wolf werden, oder als Schaf sterben.
(Syrisches Sprichwort)
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Schwarzer Wolf hat geschrieben:
snafu hat geschrieben: Es gibt ja häufig Situationen, wo man Hilfskonstrukte benötigt, um bestimmte Abläufe zu vereinfachen
Du meinst damit Klassen, die dem "struct" bei "C" ähneln?
Die waren nicht gemeint, nur weil sie zufällig so ähnlich klingen... :D

Klassen in der Art eines structs, die also vorwiegend zur Datenhaltung gedacht sind, kann man in Python gut mit einem namedtuple umsetzen. Übrigens ist das so ein typisches Beispiel, wo ich wenig Sinn sehe, es vor dem Anwender zu verstecken. Mag sein, dass 90% der Benutzer keine Verwendung darin sehen, aber der übrige Teil möchte vielleicht spezifische Anpassungen vornehmen, ohne größere Abschnitte des Programms neuschreiben zu müssen. Hier können gut dokumentierte namedtuples eine große Hilfe sein. Ich benutze die auch gerne mal, wenn ich umfangreiche Optionen anbiete, die durch mehrere Ebenen meines Programms gereicht werden. Da ist ein zusammenfassendes namedtuple, in dem ich an einer Stelle im Programm die Standardwerte definiert habe, eine praktische Sache. Die Alternative wären "riesige" Signaturen, die man für die betreffenden Funktionen oder Klassen jedes Mal kopieren und im Docstring erklären müsste.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Michael Weigend ist Informatiklehrer und hat bereits mehrere Bücher zu Python geschrieben wie z.B. Python Ge-Packt.
Quelle: https://mitp.de/Unsere-Autoren/Michael-Weigend/

Da ärgert es umso mehr, wenn sich der Autor nicht an elementare Dinge wie PEP8 hält (vermutlich eine bewusste Entscheidung).
Antworten