private-Mechanismus [war: benchmark.py]

[jens]

Abgetrennt von http://www.python-forum.de/topic-7735,15.html

Das finde ich sinnvoll weil keiner diese Sachen anfassen soll und ich die auch nicht dokumentieren werde, wie es schon in PEP8 vorgeschlagen wird. Also self._functions, self._data, self._refTime sind für Interna bestimmt (also private) und sollen von außen _nicht_ angerührt werden. Falls ich damit falsch liege und es nicht so ist dann bitte berichtigen.

Das liegt in deinem Ermessen, du kannst es so oder so machen. Ich persönlich halte von sowas eigentlich nicht viel, weil mich die ganze Problematik (und Dogmatik) mit dem Private/Public total kalt lässt. Kann ich dir jetzt wirklich schwer erklären, bei mir ist es eben Einstellungssache. YMMV. Ich meine, wenn der Programmierer in der Klasse rumfischen will, ok, wenns auseinanderfällt ist er selbst schuld.

IMHO geht es nicht nur darum, das andere Programmierer rumfischen und so evtl. was kaputt machen. Gerade wenn man mit mehreren Leuten an einem Projekt arbeitet kann das hilfreich sein. Nicht weil man ein Programmiere böse absichten unterstellt oder so... Viel mehr geht es darum externe Leute, aber man auch selber, erkennt, das das ein oder andere Attribut/Methode nur intern zu gebrauchen ist.
Das kann hilfreich sein, wenn man z.B. selber nicht mehr weiß was man da gemacht hat, weil es schon so lange her ist.

Ich selber mache aber davon bisher auch ehr selten Gebrauch. Das kommt aber daher, das ich diesen Mechanismus noch nicht all zu lange kenne Also Nachholbedarf ist da an vielen Codestellen in PyLucid

btw. die Wiki Seite [wiki]public/private-Mechanismus[/wiki] sollte man vielleicht mal überarbeiten...

[sape]

Hallo jens

[...]
Nicht weil man ein Programmiere böse absichten unterstellt oder so... Viel mehr geht es darum externe Leute, aber man auch selber, erkennt, das das ein oder andere Attribut/Methode nur intern zu gebrauchen ist.
Das kann hilfreich sein, wenn man z.B. selber nicht mehr weiß was man da gemacht hat, weil es schon so lange her ist.
[...]

So sehe ich das auch. Ich quote mich mal selber:

Vielen Dank! Ich werde deine Vorschläge alle umsetzen! Außer das mit den _, das behalte ich bei, weil ich doch gerne damit signalisieren will, das die Attribute damit Privat sind. Ja ich weiß, ist ein dogam von C++ aber ist nun mal zu tief drin bei mir Außerdem, wenn ich dann mal wirklich ein Public Attribut habe, worauf man zugreifen muss, dann verliere ich selber die Übersicht ^^
[..]

Genau darum ging es mir ja. Das dient ja nicht nur der Übersicht für die anderen, sondern auch für einen selber. Wenn ich z.B. ein par Hilfsmethoden für andere Methoden in der jeweiligen Klasse schreibe, die aber nur private sinnvoll sind, dann kennzeichne ich die auch mit einen unterstrich. Damit Signalisiere ich ja dass die Methode nicht dafür bestimmt ist außerhalb der Klasse zu nutzen. Ergo: Erhöhung der Übersicht. Außerdem machen davon eigentlich alle Klassen Gebrauch (Sofern die Sachen haben die für interen Zecke bestimmt sind), was ich sehr begrüsse.

Immer wenn ich mir ein neues Modul ansehe und sehe das da Atribute, Methoden oder Funktionen mit eine unterstrich (In C++ = private) oder zwei unterstrichen (in C++ = Protected) beginnen, dan weiß ich: "OK, das ist nur für interne zwecke in der Klasse oder des Moduls bestimmt und hat mich nicht zu interessieren. Alles was ich brauch um die Klasse/Modul zu benutzen, beginnt ohne unterstrich(e)"


Von daher, finde ich das es ein sehr sauberer Stil ist das zu verwenden

lg xtra