Seite 2 von 3

Verfasst: Dienstag 3. Februar 2009, 13:54
von bwbg
Naja, dafür ist es ja auch nicht gedacht. Wer z.B. ein Feld "password" private macht nur weil keiner ran soll hat was falsch verstanden.
Sinnhaftigkeit unterscheidet sich meist sehr oft von Machbarkeit :wink: - Mir ging es aber nicht um die Objektsicherheit was die Geheimhaltung des Inhaltes betrifft, sondern vielmehr die Objektsicherheit hinsichtlich der Manipulation von Interna.

Mir (in meiner hobbymäßig, oberflächlichen Beschäftigung mit C++) ist bislang noch kein Anwendungsfall untergekommen, einen reinterpret_cast zu verwenden - dynamic_cast und const_cast (gerade in Verbindung mit C-Libs) schon eher.

Das driftet jetzt aber doch etwas ab...

Grüße... Heiko

Verfasst: Samstag 7. Februar 2009, 20:54
von PythonÜbernehmenSie
Ich möchte mich in die Diskussion als bisher nur passiver Leser auch mal einbringen. Vielleicht teilt ja jemand meine augenscheinliche Vorliebe für klar strukturierte, aber etwas lange Sätze :wink:

Zu der Private/Public-Problematik fällt mir ein schönes Zitat ein, das ich in einem anderen Forum gelesen hab:
private schützt vor Murphy, nicht vor Macchiavelli.
Klar ist. dass ich (zumindest in einer Umgebung, die Zeigerarithmetik unterstützt) immer an private Attribute komme, wenn ich es wirklich will. Aber greife ich z.B. in C++ auf eine private Eigenschaft zu, erhalte ich eine Fehlermeldung des Compilers. Durch casten oder Zeigerspielereien komme ich wie gesagt natürlich an die Daten ran, aber da ist ein zunächst einmal gewissser Aufwand dabei. Die Konvention, _ als Präfix für privat gemeinte Attribute zu verwenden, wird dagegen nur durch die Disziplin des Verwenders der Klasse durchgesetzt - ein absichtliches Zugreifen auf ein solches Element ist also als solches erst nach näherer Analyse des Codes und gggf. Konsultation der Dokumentation zu ersehen.

Meiner Ansicht nach sollte eine gute Programmiersprache den Programmierer insofern bevormunden, dass konzeptuell "schlechte" Verhaltensweisen zwar möglich, aber mit höherem Aufwand verbunden sind. Und das Aushebeln der Steuerung, welche Programmteile auf welche Attribute eines Objektes wie zugreifen dürfen und welche nicht, ist meines Erachtens bei einer Sprache, die (u.a.) das objektorientierte Programmierparadigma unterstützt, konzeptionell eher "schlecht".

Als ich mir das erste Mal Python angesehen habe, kam es mir deshalb auch unverständlich vor, dass es für diese Zugriffssteuerung in Python keine Unterstützung seitens der Sprache gibt.

Verfasst: Samstag 7. Februar 2009, 21:33
von str1442
Meiner Ansicht nach sollte eine gute Programmiersprache den Programmierer insofern bevormunden, dass konzeptuell "schlechte" Verhaltensweisen zwar möglich, aber mit höherem Aufwand verbunden sind.
Der höhere Aufwand ist, "_" im Attributsnamen zu sehen und daraufhin die Dokumentation zu konsultieren. Wer das nicht tut, ist selbst schuld wenns richtig kracht.

Wenn es einen höheren Aufwand gibt, dann sollte dieser auch mehr oder weniger klar und einfach sein und nicht aus irgendwelchen Hacks bestehen. Das Benutzen von irgendwelchen Pointer Spielereien oder #define private public kann man wohl kaum als einen "standarisierten" Weg zu beschreiben, oder?

Verfasst: Samstag 7. Februar 2009, 22:40
von PythonÜbernehmenSie
str1442 hat geschrieben: Der höhere Aufwand ist, "_" im Attributsnamen zu sehen und daraufhin die Dokumentation zu konsultieren. Wer das nicht tut, ist selbst schuld wenns richtig kracht.
Die Sache mit _ ist eben keine Eigenschaft der Sprache, sondern eine Konvention, die der Programmierer der Klasse einhält - oder auch nicht. Es ist ein unverbindlicher Vorschlag, mehr nicht. Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten. Also bleibt mir, den Quellcode der Fremdklasse anzusehen - super, ich hab ja sonst nichts besseres zu tun.

Es geht mir nicht zwingend um die Auftrennung in private, protected und public - es geht um Zugriffssteuerung auf Objektklassenebene an sich. Sehr viele Sprachen benutzen dafür eben diese drei (teilweise auch mehr) Sichtbarkeitsbereiche, eventuell kombiniert mit spezifisc hen "Freundschaften", was sicher nicht der Weisheit letzter Schluss ist, aber es funktioniert halbwegs! Python aber verfügt über keinen solchen Mechanismus. Mein Eindruck, der in diesem Thread durchaus bestätigt wird, ist der, dass im Alltag so etwas aber durchaus benötigt wird - deswegen wird der Benennungsvorschlag mit _ empfohlen.

Wenn dieser Mechanismus also in vielen Fällen angebracht ist, warum ihn dann so verwirklichen, dass er ohne den geringsten Aufwand ausgehebelt werden kann? Von diesem Gesichtspunkt aus betrachtet stellt das Fehlen eines solchen Mechanismus eine Designschwäche der Sprache dar, die auf der semantischen Metaebene der Benennung ausgeglichen werden soll.

Verfasst: Samstag 7. Februar 2009, 22:46
von Hyperion
PythonÜbernehmenSie hat geschrieben: Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten. Also bleibt mir, den Quellcode der Fremdklasse anzusehen - super, ich hab ja sonst nichts besseres zu tun.
Also ich denke man sollte gerade eine gute Dokumentation erwarten können! Was nützt Dir ein Modul ohne Doku? Nichts! Aber das ist doch in jeder Sprache so ;-)
Wenn dieser Mechanismus also in vielen Fällen angebracht ist, warum ihn dann so verwirklichen, dass er ohne den geringsten Aufwand ausgehebelt werden kann? Von diesem Gesichtspunkt aus betrachtet stellt das Fehlen eines solchen Mechanismus eine Designschwäche der Sprache dar, die auf der semantischen Metaebene der Benennung ausgeglichen werden soll.
Also ich habe das noch nie benutzt - mag aber sein, dass ich nicht grad nen Python-Gott bin und meine Erfahrung da nicht zählt ;-)

Verfasst: Samstag 7. Februar 2009, 22:52
von PythonÜbernehmenSie
Hyperion hat geschrieben:[Also ich denke man sollte gerade eine gute Dokumentation erwarten können! Was nützt Dir ein Modul ohne Doku? Nichts! Aber das ist doch in jeder Sprache so ;-)
Wenn mir eine für mich neue Klasse bzw. ein neues Modul unter die Hände kommt, kuck ich mir zunächst einmal die öffentlichen "Kommandos" und Attribute an. Sind die aussagekräftig benannt, kann ich mit ihnen zumindest schonmal grundlegend arbeiten, ohne in die Doku zu kucken. Und bevor man bei jedem beliebigen Projekt eine vernünftige Doku erwarten kann, erscheinen GNU/Hurd und Duke Nukem Forever...
Also ich habe das noch nie benutzt - mag aber sein, dass ich nicht grad nen Python-Gott bin und meine Erfahrung da nicht zählt ;-)
Meine Python-Kenntnisse sind auch bescheiden, aber ich beziehe mich ja auch die Tatsache, dass andere "gängige" Sprachen so etwas haben, Python aber nicht. Was ja auch ein Teil der Ausgangsfrage ist.

Verfasst: Samstag 7. Februar 2009, 23:01
von Hyperion
PythonÜbernehmenSie hat geschrieben: Wenn mir eine für mich neue Klasse bzw. ein neues Modul unter die Hände kommt, kuck ich mir zunächst einmal die öffentlichen "Kommandos" und Attribute an. Sind die aussagekräftig benannt, kann ich mit ihnen zumindest schonmal grundlegend arbeiten, ohne in die Doku zu kucken.
ALso nun widersprichst Du Dir aber ein wenig ... vorhin hast Du Dich noch darüber muckiert, in den Quellcode reinzugucken! Nun soll's auf einmal ein gutes Mittel sein ... (was es ja sogar ist - passt halt nur nicht zu Deiner obigen Aussage!)
Und bevor man bei jedem beliebigen Projekt eine vernünftige Doku erwarten kann, erscheinen GNU/Hurd und Duke Nukem Forever...
Also ich nutze nicht jedes beliebige Projekt, sondern eben die, die ich geeignet finde. Für das "geeignet"-Prädikat sind die Doku und ggf. auch Tutorials für mich durchaus eines der wichtigsten Kriterien!
Meine Python-Kenntnisse sind auch bescheiden, aber ich beziehe mich ja auch die Tatsache, dass andere "gängige" Sprachen so etwas haben, Python aber nicht. Was ja auch ein Teil der Ausgangsfrage ist.
Also das ist doch nun irgend wie platt: "Wenn alle aus dem Fenster springen, muss das ja gut sein!" Ok, weniger überspitzt: Python hat ja auch Dinge, die andere Sprachen nicht bieten. Sind die dann in den Punkten auch "schwach" designt? Wenn das so wäre und man diese "MIsstände" beseitigen müßte, würde das schließlich auf eine Universelle Sprache zusteuern ... so eine Art "Volksprogrammiersprache" :-D SCNR

Davon mal abgesehen, dass jede Sprache ihre eigenen Paradigmen hat!

Verfasst: Samstag 7. Februar 2009, 23:17
von PythonÜbernehmenSie
Hyperion hat geschrieben:ALso nun widersprichst Du Dir aber ein wenig ... vorhin hast Du Dich noch darüber muckiert, in den Quellcode reinzugucken! Nun soll's auf einmal ein gutes Mittel sein ... (was es ja sogar ist - passt halt nur nicht zu Deiner obigen Aussage!)
Nicht ich kucke in den Quellcode, sondern ein Teil meiner IDE - das Ergebnis bekomme ich dann idealerweise an der Stelle angezeigt, an der ich einen entsprechenden Aufruf oder Zugriff tätigen könnte.
Davon mal abgesehen, dass jede Sprache ihre eigenen Paradigmen hat!
Das würde ich nicht sagen. Ich sage, es gibt eine gewisse Anzahl an Programmierparadigmen, die natürlich recht abstrakt sind. Diese Paraidgmen werden dann in Sprachen auf verschiedene Art und Weise umgesetzt, eine Sprache wie Python setzt dabei mehrere Paradigmen (z.B. objektorienierte, prozedurale, funktionale) um. In dieser Diskussion geht es um das objektorienierte Paradigma. Dieses wird in Python durch den Einsatz von Klassen ermöglicht, in vielen anderen Sprachen (z.B. C++, Java, C#, Ruby) auch. In diesen Sprachen besitzen Klassen vor allem so Elemente wie Attribute, Methoden und Operatoren, Vererbung und eben auch Zugriffsschutz durch Sichtbarkeit. Python verfügt über die ersten drei, aber eben nicht über letzteres.

Soll heißen: Obwohl im Bereich der objektorientierten Programmierung eine starke Gemeinsamkeit mit anderen Sprachen herrscht, fehlt die Sichtbarkeitssteuerung.
Das ist ja zusammengefasst die Ausgangssituation.

Die Frage ist jetzt:
Braucht man diese Sichtbarkeitssteuerung und wenn ja, ist es ein Nachteil, dass Python so etwas nicht hat?

Verfasst: Samstag 7. Februar 2009, 23:31
von str1442
Die Sache mit _ ist eben keine Eigenschaft der Sprache, sondern eine Konvention, die der Programmierer der Klasse einhält - oder auch nicht. Es ist ein unverbindlicher Vorschlag, mehr nicht.
Und in Java, C++ etc pp schreibt sich das "private" magisch vor die Variablen? Die ganze private, protected, public Geschichte ist nichts Essenzielles. Ein Programm funktioniert auch ohne das Zeug recht gut, egal in welcher Sprache. Warum es also "hart" (also syntaktisch) erzwingen? Und auf "_" wird sicherlich in jedem guten Tutorial hingewiesen. Aber ich finde auch Minimalismus toll.
Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten.
Worauf verlassen? Das das Teil keiner anfassen kann? Wo ist eigentlich das Problem? Wenn jemand das nicht (doppelte Verneinung :D) tut, ist das schlicht sein Problem. Entweder er weiß, was er tut, oder es kracht. Und jetzt erklär mir doch bitte noch, warum du in C++ *ohne* Dokumentation mit deinen Pointer Tricks mit pseudoprivaten Variablen besser dran bist als in Python ohne Dokumentation und mit "_".

Verfasst: Samstag 7. Februar 2009, 23:36
von Hyperion
PythonÜbernehmenSie hat geschrieben: Nicht ich kucke in den Quellcode, sondern ein Teil meiner IDE - das Ergebnis bekomme ich dann idealerweise an der Stelle angezeigt, an der ich einen entsprechenden Aufruf oder Zugriff tätigen könnte.
Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!

Verfasst: Samstag 7. Februar 2009, 23:37
von PythonÜbernehmenSie
Stellvertretend für den ganzen Post beantworte ich nur diesen Satz:
str1442 hat geschrieben: Und jetzt erklär mir doch bitte noch, warum du in C++ *ohne* Dokumentation mit deinen Pointer Tricks mit pseudoprivaten Variablen besser dran bist als in Python ohne Dokumentation und mit "_".

Greife ich in Python auf ein privates Objektattribut zu, sehe ich es bestenfalls am Namen; schlimmstenfalls gar nicht.
Greife ich in C++ auf ein privates Objektattribut zu, gibt es dagegen einen Compilerfehler.

Verfasst: Samstag 7. Februar 2009, 23:39
von PythonÜbernehmenSie
Hyperion hat geschrieben: Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!
Eben nicht:

- "private" ist ein Sprachelement, das verbindlich ist.
- "_" als Namensteil ist lediglich eine unverbindliche Empfehlung.

Verfasst: Samstag 7. Februar 2009, 23:47
von Hyperion
PythonÜbernehmenSie hat geschrieben:
Hyperion hat geschrieben: Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!
Eben nicht:

- "private" ist ein Sprachelement, das verbindlich ist.
- "_" als Namensteil ist lediglich eine unverbindliche Empfehlung.
Ja aber der Programmierer muss sich doch in beiden Fällen damit auseinandersetzen! Ich sehe da Dein Problem nicht ganz.

Ich kann in Java doch auch alles public deklarieren - wo ist dann da der Vorteil, dass das ganze syntaktisch ist? So oder so muss sich der Entwickler dazu "bereit erklären", interne Strukturen auch vernünftig zu kennzeichnen.

Und wie Du ja auch schon geschrieben hast, ist eine gute Benennung von Methoden und Funktionen eben Gold wert!

Verfasst: Samstag 7. Februar 2009, 23:48
von str1442
Greife ich in Python auf ein privates Objektattribut zu, sehe ich es bestenfalls am Namen; schlimmstenfalls gar nicht.
Greife ich in C++ auf ein privates Objektattribut zu, gibt es dagegen einen Compilerfehler.
Und schlimmstenfalls hatt in C++ jemand statt private durchweg public benutzt und du erkennst es auch gar nicht. Das war mein Punkt mit "magisch". Es liegt immer am Programmierer. "_" wird mit an Sicherheit grenzender Wahrscheinlichkeit nicht weniger oft empfohlen wie private in C++, höchstens erst später.

Verfasst: Samstag 7. Februar 2009, 23:53
von Hyperion
PythonÜbernehmenSie hat geschrieben: Greife ich in Python auf ein privates Objektattribut zu, sehe ich es bestenfalls am Namen; schlimmstenfalls gar nicht.
Was ist daran so schlimm? Was sagt Dir denn das "private" in anderen Sprachen, was Dir in Python "fehlt"?

In Java musst Du eben einen getter benutzen, um an den Wert des Attributes zu gelangen. Schön. Das kann ich in Python per property ebenfalls realisieren. D.h. der Zugriff ist gekapselt, ohne dass Du das merkst.

Die Gefahr die Du beschreibst ist doch damit genauso gut gebannt, wie bei C++ / Java!

Verfasst: Sonntag 8. Februar 2009, 00:01
von PythonÜbernehmenSie
Hyperion hat geschrieben: Ich kann in Java doch auch alles public deklarieren - wo ist dann da der Vorteil, dass das ganze syntaktisch ist? So oder so muss sich der Entwickler dazu "bereit erklären", interne Strukturen auch vernünftig zu kennzeichnen.
Der Vorteil ist in meinen Augen der, dass im Falla Javas die Sprache genau einen Weg vorgibt, wie man es machen kann. Im Falle Pythons gibt die Sprache eben nichts vor und überlässt es der Phantasie der Entwickler. Diese erarbeiten dann gewisse Empfehlungen, von denen es entweder verschiedene, sich widersprechende gibt. Verwende ich eine fremde Klasse, so muss ich erst herausfinden, an welche Empfehlung sich der Autor der Klasse gehalten hat.

In diesem Fall ist es anscheinend so, dass die Verwendung von "_" weitgehend unwidersprochen ist; es existieren also keine beachteten Alternativempfehlungen. In diesem Fall wäre es aber doch konsequent, dies in die Sprache selbst aufzunehmen. Der Vorteil: Nur noch der Autor muss die Empfehlung kennen, der Benutzer der Klasse würde bei einer "falschen" Verwendung eine entsprechende Meldung erhalten.

Es ist aber gut zu wissen, dass der Meinungsunterschied zwischen Hyperion sowie str1442 und mir nicht darin besteht, ob ein Sichtbarkeitsmodifikator notwendig ist, sondern nur noch, wie dieser auszusehen vermag. Sowas engt doch schon mal gewaltig den Kriegsschauplatz ein! :) [/i]

Nachtrag;:
Hyperion hat geschrieben:Was ist daran so schlimm? Was sagt Dir denn das "private" in anderen Sprachen, was Dir in Python "fehlt"?
Auch wenn ich mich wiederhole: Mir sagt es nicht mehr, aber dem Compiler. Und ein Abbruch der Kompilierung (bzw. der Interpretierung) bemerkt man ;-)

Verfasst: Sonntag 8. Februar 2009, 00:16
von BlackJack
@PythonÜbernehmenSie: Dein Eindruck das Zugriffsteuerung im Alltag benötigt wird, kann nicht durch die Namenskonvention mit dem '_' bestätigt werden. Das bestätigt nur, dass im Alltag eine leichte Unterscheidung zwischen öffentlicher API und Interna benötigt wird. Daraus folgt nicht automatisch das es erzwungenen Zugriffschutz geben muss. Wenn das so wäre müsste es bei Python-Programmen ja ständig Probleme damit geben.

Wenn Du schreibst, das viele Sprachen so etwas haben, in zwei, drei oder mehreren Feinheitsgraden und es halbwegs funktioniert, halte ich dagegen, dass der Weg über Dokumentation und Namenskonventionen ebenfalls halbwegs funktioniert.

Also lautet die Antwort, nein man braucht keine Sichtbarkeitssteuerung, und nein das Fehlen einer solchen ist kein Nachteil. :-)

Warum muss man Programmierer davor beschützen sich in den Fuss zu schiessen, wohlgemerkt in Fällen wo das nicht aus versehen passiert! Wer ein '_'-Attribut verwendet, tut das vorsätzlich. Wer das ständig, und ohne gute Gründe tut, wird auch sonst genug Blödsinn anstellen, vor dem ihn keine noch so restriktive Sprache schützen kann.

Übrigens wird die Konvention auch von der Sprache selbst unterstützt. Ein ``from some_module import *`` importiert alle Namen aus `some_module` ins importierende Modul, *ausser* die, die mit einem Unterstrich beginnen.

Was meinst Du damit wenn Du sagst man sollte die '_'-Konvention in die Sprache aufnehmen? Darauf zuzugreifen, auch von aussen, ist *kein Fehler*! '_' bedeutet nicht "privat, auf keinen Fall anfassen", sondern "Interna, nur anfassen, wenn Du weisst was Du tust". Die Sprachimplementierung kann da unmöglich eine "falsche" Verwendung erkennen und melden.

Und ich habe nicht den Eindruck, das Hyperion und str1442 Deiner Meinung sind, dass ein Sichtbarkeitsmodifikator nötig ist, sondern Du fälschlicherweise Kennzeichnung von Interna mit hartem Zugriffschutz gleichsetzt. Aus ersterem folgt nicht zwangsläufig letzteres.

Verfasst: Sonntag 8. Februar 2009, 00:17
von BlackVivi
PythonÜbernehmenSie hat geschrieben:
Hyperion hat geschrieben: Ich kann in Java doch auch alles public deklarieren - wo ist dann da der Vorteil, dass das ganze syntaktisch ist? So oder so muss sich der Entwickler dazu "bereit erklären", interne Strukturen auch vernünftig zu kennzeichnen.
Der Vorteil ist in meinen Augen der, dass im Falla Javas die Sprache genau einen Weg vorgibt, wie man es machen kann. Im Falle Pythons gibt die Sprache eben nichts vor und überlässt es der Phantasie der Entwickler. Diese erarbeiten dann gewisse Empfehlungen, von denen es entweder verschiedene, sich widersprechende gibt. Verwende ich eine fremde Klasse, so muss ich erst herausfinden, an welche Empfehlung sich der Autor der Klasse gehalten hat.
Es gibt nur eine Empfehlung. Genauso wie bei der Namenskonvention und auch sonst. Zwar überlesen die scheinbar einige Leute gern... aber das gibts auch bei Java und allen anderen Programmiersprachen.

http://www.python.org/dev/peps/pep-0008/

Hier steht:
Use one leading underscore only for non-public methods and instance variables.
Viel eindeutiger gehts nich, oder? Das ist kein Dokument von irgendwen, sondern von den Pythonentwicklern.

Verfasst: Sonntag 8. Februar 2009, 00:35
von EyDu
PythonÜbernehmenSie hat geschrieben:Auch wenn ich mich wiederhole: Mir sagt es nicht mehr, aber dem Compiler. Und ein Abbruch der Kompilierung (bzw. der Interpretierung) bemerkt man ;-)
Also wenn du/man den Schutzt nicht benötigt, weil dieser nicht mehr aussagt, dann braucht man ihn überhaupt nicht. Dem Compiler ist es egal, ob er alles public machen oder zwischen Sichtbarkeitsebenen unterscheiden soll.

Wer ein mit "_" als private markiertes Attribut "aus Versehen" benutzt, der wird sicher auch in Java seine Attribute public machen. Dort ist es auch nur Konvention, dass man dazu get- und set-Methoden verwendet und die dazugehörigen Attribute entsprechend markiert.

Man kann Sichtbarkeiten eben nicht von der Sprache erzwingen, am Ende entscheidet es immer der Programmierer. Dann macht es in meinen Augen auch keinen Sinn noch Steine in den Weg zu werfen, nur weil, ein möglicherweise anderer Entwickler, meinte, andere vor sich selbst schützen zu müssen. Wenn man der Meinung ist, an einer gewissen Stelle entgegen der Empfehlung zu handeln, weil es sinnvoll ist, dann soll man dies doch bitte auch tun können.

Verfasst: Sonntag 8. Februar 2009, 01:01
von str1442
In diesem Fall ist es anscheinend so, dass die Verwendung von "_" weitgehend unwidersprochen ist; es existieren also keine beachteten Alternativempfehlungen.
Ja, genau wie in Java mit public, private, protected. Ich könnte auch anfangen und in Java, würde ich diese Sprache denn nutzen, _ zu benutzen und ansonsten alles public zu machen. Das wäre dann auch eine Alternative. Es ist eben nichts, was absolut notwendig wäre für ein Programm, egal in welcher Sprache! Nur ist eine solche Unterscheidung nunmal recht praktisch. Ich stimme also BlackJack vollkommen zu.