Properties und Getters

[PythonÜbernehmenSie]

Stellvertretend für den ganzen Post beantworte ich nur diesen Satz:

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.

[PythonÜbernehmenSie]

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.

[Hyperion]

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!

[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.

[Hyperion]

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!

[PythonÜbernehmenSie]

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;:

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

[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.

[BlackVivi]

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.

[EyDu]

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.

[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.

[PythonÜbernehmenSie]

Nun gut, ich sehe, dass ich mit meiner Meinung anscheinend alleine stehe. Ich meinte niemals, dass die Sichtbarkeitssteuerung ein "harter" Zugrifssschutz sei, der nicht oder nur schwer überwunden werden könnte, sondern es ist eben ein Schutz, der nicht ausversehen überwunden wird.

Der Hintergrund bei mir ist vielleicht auch der, dass ich, als mich zum ersten Mal mit Python beschäftigte, nichts von der Konvention mit "_" gelesen habe. Da "private" und "public" z.B. bei Java Schlüsselworter sind und darüber hinaus schon in den einfachsten Programmen vorkommen, gerät man beim Lernen von Java schon von Beginn an zwangsläufig mit der Problematik in Erfahrung.
Ich stimme aber zu, dass das weniger ein Problem der Sprache an sich sondern eher eines des Lernens selbiger ist.

Danke auf jeden Fall an die vielen Antworten. Ich habe mich bisher immer mit Sprachen beschäftigt, die in dieser Angelegenheit restriktiver sind als Python es ist, und ich habe mich damit recht wohl gefühlt und diesen Mechanismus deshalb bei Python vermisst. Unter der Prämisse, dass die Teilnehmer dieser DIskussionsrunde halbwegs repräsentativ sind, ist es aber anscheinend so, dass ich damit eine Minderheit bin. Vielleicht muss ich ja erst ein größeres Projekt in Python abschließen, um den Vorteil darin zu sehen.

[BlackJack]

@PythonÜbernehmenSie: Es würde ja schon genügen, wenn Du keinen Nachteil darin siehst.

Die Meinungen hier sind IMHO halbwegs repräsentativ für "Pythonistas", denn die gleiche Diskussion gibt's regelmässig in der englischsprachigen Python-Newsgroup. Dort wird sie auch oft von Java-Programmierern angezettelt, die gerne ``private`` & Co in Python sehen würden. Als nächstes kommt dann Typdeklaration.

Stell Dir mal umgekehrt vor, man würde in einem Java-Forum die Abschaffung von ``private``, ``protected``, und ``public`` vorschlagen und statt dessen eine Namenskonvention wie den führenden Unterstrich anregen.