Objektvariablen in __init__ werden nicht gesetzt.

[Hyperion]

Wenn ich das richtig verstanden habe, könnte man also meinen, dass Zugriffsschutz klar stellt, dass man ein Attribut nicht direkt manipulieren sollte, sondern dies nur über getter / setter oder was auch immer erreichen kann. Dafür gibts aber in Python doch properties? Damit kann ich doch leicht den gleichen Effekt erzielen?

Ich würde eigentlich auch denken, dass doch eine gute Dokumentation der entscheidene Aspekt für eine Schnittstelle sein muss. Wenn ich bei einer Variablen darauf hinweise, dass man diese möglichst nicht von extern nutzen sollte, reicht das doch vollkommen aus. Wo ist der Zusatznutzen, wenn ich so etwas wie privat davor schreibe? Nur dass mich der Compiler ggf. warnt und meckert und ich daraus implizit schließen muss, dass das nicht erwünscht ist? Da finde ich eine explizite Aussage in der Doku doch hilfreicher... nicht jeder steht auf "trial and error"

[MikeScript]

Zum Thema:

http://code.activestate.com/recipes/389916/
Danach habe ich es gelöst. Das macht nun genau was ich erwartet habe.

Zur Diskussion:
Ich vermisse private, public, protected schon ein bisschen. Das half immer bei Vererbung.

Ein Hinweis in einer Doku zu geben finde ich nicht so gut. Wer hat schon Lust mehrere Seiten zu lesen was er alles nicht darf. Das soll auch nicht wie JAVA werden, aber ohne diese drei fehlt einfach was.

[EyDu]

Ein Hinweis in einer Doku zu geben finde ich nicht so gut. Wer hat schon Lust mehrere Seiten zu lesen was er alles nicht darf.

In Java musst du genau so Dokumentation lesen um das zu erfahren. Du konntest es dir nur sparen, weil es dir irgendjemand erzählt hat oder weil du es in einem Tutorial gelesen hast.

Das soll auch nicht wie JAVA werden, aber ohne diese drei fehlt einfach was.

Verstehe mich jetzt bitte nicht falsch, aber deiner Frage nach hast du noch nicht so viel Erfahrung mit Python, dass du das zu diesem Zeitpunkt schon bewerten könntest

[hendrikS]

...

Also was ich alles für Obst kenne ist wohl ein anderes Thema.
Ich finde, dass die aktuelle Unterstrichkonvention reichlich unprofessionell ist und durchaus mit sprachspezifischen Mitteln sauber gelöst werden könnte.
Zu argumentieren, es tut ja ganz gut im Moment so wie es ist, ist auch etwas mager. Dann müsste man den Sinn von ja Py3 ja voll und ganz in Frage stellen.
Aber gut, jeder hat so seine eigene Sicht der Dinge. Und der Erfolgt gibt Python im Moment wohl recht. Also gibt es offenbar nichts zu verbessern in Python.

[EyDu]

Ich finde, dass die aktuelle Unterstrichkonvention reichlich unprofessionell ist und durchaus mit sprachspezifischen Mitteln sauber gelöst werden könnte.

Da du es uns nicht verraten möchtest: was wird denn so großartiges gelöst, dass man etwas sprachlich "erzwingen" muss?

[Leonidas]

Also was ich alles für Obst kenne ist wohl ein anderes Thema.

Nein, eigentlich nicht. Du argumentierst damit dass es in anderen Sprachen auch so ist und Darii und ich argumentieren dass es eben durchaus Sprachen gibt wo es eben keine private-Konvention gibt. CLOS ist da etwas exotisch, das gebe ich gerne zu, aber Smalltalk als Wiege von OOP selbst sollte einem zu denken geben und die bekannteste Prototypenbasierte Sprache, JavaScript ebenso.

Ich finde, dass die aktuelle Unterstrichkonvention reichlich unprofessionell ist und durchaus mit sprachspezifischen Mitteln sauber gelöst werden könnte.
Zu argumentieren, es tut ja ganz gut im Moment so wie es ist, ist auch etwas mager. Dann müsste man den Sinn von ja Py3 ja voll und ganz in Frage stellen.

Der Sinn von Python 3 ist ja Dinge besser zu machen, was ja teils auch gelungen ist. Was genau wird denn durch ein (züsätzliches Keyword?) private besser?

[lunar]

Zu argumentieren, es tut ja ganz gut im Moment so wie es ist, ist auch etwas mager.

Zu argumentieren, es tut ja ganz gut im Moment so wie es woanders ist, ist nicht wirklich besser

[hendrikS]

Da du es uns nicht verraten möchtest: was wird denn so großartiges gelöst, dass man etwas sprachlich "erzwingen" muss?

Keine Ahnung was ich noch erklären soll. Private unterbindet den direkten Zugriff auf bestimmte Daten/Methoden von Instanzen von Klassen.
Und das kann durchaus sinnvoll sein. Die Schnittstelle wird unter Umständen zu kompliziert, wird falsch angewendet. Daten werden unter Umständen so gesetzt, dass ein implementierter Algorithmus ausgehebelt wird.
Als Anwender bin und sollte ich nur am Interface interessiert sein.

[Leonidas]

Keine Ahnung was ich noch erklären soll. Private unterbindet den direkten Zugriff auf bestimmte Daten/Methoden von Instanzen von Klassen.

Tut es doch gar nicht, man kommt immer noch via Reflection dran, bzw in Sprachen wie C++ über Pointer.

Die Schnittstelle wird unter Umständen zu kompliziert, wird falsch angewendet.

Und wo ist der Unterschied zur Bodenstrich-Konvention, außer dass man die Bodenstrich-Konvention einfacher als via Reflection umgehen kann? In beiden Fällen muss man halt dem Nutzer der API vertrauen, dass er nicht auf private Attribute zugreift.

Ich glaube wir drehen uns auch irgendwie im Kreis. Du weißt nicht was du erklären sollst und wir wissen nicht, wo das Problem beim Bodenstrich ist.

[EyDu]

Ja, aber wo ist der Vorteil gegenüber ein Konvention? Man sollte meinen, dass ein Programmierer nicht so dämlich ist und einfach so dagegen verstößt. Wenn ich meine, dass ich irgendwas geschütztes ändern möchte, dann will ich das auch tun können, da ich weiß was ich mache. Mit private muss man hingegen unglaubliche Verrenkungen mach.

[hendrikS]

Ja, aber wo ist der Vorteil gegenüber ein Konvention?

Ja Konventionen lassen sich nicht kompielieren oder interpretieren. Es sei denn man nutzt lint oder so was. Hört sich auch so an als wären alle perfekte Programmierer. Woher kommen dann all die Segmentation faults, runtime errors, Dr. Watsons etc. Weil alle ja so perfekt programmieren und einen so richtig super OO Ansatz haben. pr pu prot unterstützt durchaus auch die defensive Programmierung.
Na ja. Ich bin jetzt der Diskussion doch ein bisschen müde. Wie Leonidas festgestellt hat, funktioniert es ja, und wahrscheinlich habe ich von dem Thema ja auch gar keine Ahnung.

[snafu]

Die Segfaults und sowas kenne ich aber eher von Sprachen wie C...

Wenn Python auf ein unerwartetes Objekt trifft, dann wirft es dir ne Exception. Den Traceback kann man zurückverfolgen und sieht dann, woran es hapert.

Und wenn ein Skript zwar durchläuft, aber komische Ergebnisse liefert, weil der Programmierer an den internen Abläufen rumgefummelt hat, dann muss der Programmierer auch mit sowas rechnen. Wie gerade schon jemand sagte: Wenn ich die Konvention zu der mit ``_`` gekennzeichneten Objekte missachte, sollte ich wissen, was ich tue und unerwartete Resultate einkalkulieren.

[Leonidas]

Woher kommen dann all die Segmentation faults, runtime errors, Dr. Watsons etc. Weil alle ja so perfekt programmieren und einen so richtig super OO Ansatz haben.

Das illustriert deinen Punkt irgendwie nicht, denn das sind entweder C-Programme, die kein private haben, aber andererseits auch sowieso keine OOP-Unterstützung oder C++-Programme, die durchaus private haben und wie du ganz richtig feststellst, trotzdem crashen.

[BlackJack]

@hendrikS: Wenn ``private`` vor so etwas schützt, dann dürfte es in Sprachen die den Zugriffschutz kennen ja keine Speicherzugriffsverletzungen oder Laufzeitfehler geben. Sieht man aber bei C++ oder Java trotzdem. Im Gegenzug geht bei Python aber anscheinend die Welt ohne ``private`` auch nicht unter.