Das deutsche Python-Forum

pütone hat geschrieben:

Leonidas hat geschrieben:Aber wozu willst du das? Zudem ``__slots__`` dazu auch gar nicht gedacht sind.

Für ein Projekt, dass ich mir vorgenommen habe, wäre das aus bestimmten Gründen (das kann ich ein andermal ausführen) sinnvoll.

Wenn du __slots__ zur Zugriffsbeschränkung verwenden willst/musst, dann hast du entweder Paradigmen aus anderen Sprachen nicht ganz abgelegt, oder ein ziemlich schlechtes Design. Mit dieser Meinung dürfte ich hier nicht alleine stehen...

Nachdem was ich bisher über slots gelesen habe, sind sie genau dafür gedacht (Lutz/Ascher, S. 400f).

Wirf das Buch weg.

Hättest du einen Link für mich, wo ich nachlesen kann, wozu sie *wirklich* gedacht sind?

Das steht gleich am Anfang der offiziellen Dokumentation, die zu lesen sicherlich nicht geschadet hätte.

Mein Frage, ob (und ggf. wie) ich das von mir Gewünschte mittels __getattr__ und __setattr__ realisieren kann, ist noch unbeantwortet ...

Selbst wenn du es nicht wahrhaben willst, aber das was du versuchst, hört sich ziemlich nach dem falschen Ansatz zur Lösung eines wie auch immer gearteten Problems an

@Trundle:
Danke für den Link und das Beispiel; hat beides geholfen.

@lunar:
Mir ist bewusst, dass es gerade eine der Eigenarten von Python ist, so etwas, wie ich es will/wollte, nicht zu tun. Aber ich verstehe nicht, wie du - ohne die Problemstellung zu kennen - beurteilen kannst, dass es "schlechtes Design" oder der "falsche Ansatz" ist.

Die "offizielle Dokumentation" kenne ich auch, d.h. ich weiß, dass es sie gibt. Nein, schaden tut es sicher nicht, sie zu lesen. Das Tutorial habe ich gelesen, die Referenz zu lesen ist für einen Python-Anfänger aber ein hartes Brot. Ich könnte sie mir aber nochmal vornehmen.

In meinem Fall war es ja auch so, dass ich - in einem gedruckten Buch - etwas über slots gelesen und mich darauf gestützt hatte. Ohne Grund gehe ich ja zunächst nicht davon aus, dass das sicher nicht stimmt und ich woanders mich noch vergewissern sollte.

pütone hat geschrieben:Aber ich verstehe nicht, wie du - ohne die Problemstellung zu kennen - beurteilen kannst, dass es "schlechtes Design" oder der "falsche Ansatz" ist.

Nun, die Verwendung von __slots__ zur Steuerung der Attributzugriffe ist immer der falsche Ansatz, weil __slots__ dafür nicht gedacht ist!

Das Überscheiben von __[gs]etattr__ zur Zugriffssteuerung ist im mindesten fraglich, da "harte" Zugriffsbeschränkung nicht zu den Konzepten von Python passt.

Fazit: Wenn du Zugriffsbeschränkungen nutzen musst, dann ist höchstwahrscheinlich der Ansatz zur Problemlösung verkehrt.

Die "offizielle Dokumentation" kenne ich auch, d.h. ich weiß, dass es sie gibt. Nein, schaden tut es sicher nicht, sie zu lesen. Das Tutorial habe ich gelesen, die Referenz zu lesen ist für einen Python-Anfänger aber ein hartes Brot. Ich könnte sie mir aber nochmal vornehmen.

Der Link von Trundle hat dir offenbar aber geholfen... und das war ein Link zur offiziellen Dokumentation der nächsten Python Version. Ich habe den Link zur aktuellen Doku gepostet, die zwar nicht ganz so schön aussieht, in der aber im Bezug auf __slots__ exakt das gleiche steht.

In meinem Fall war es ja auch so, dass ich - in einem gedruckten Buch - etwas über slots gelesen und mich darauf gestützt hatte. Ohne Grund gehe ich ja zunächst nicht davon aus, dass das sicher nicht stimmt und ich woanders mich noch vergewissern sollte.

Das wäre nicht der erste Fall eines schlechten Python Buchs. Viele Bücher scheinen von fachfremden Autoren geschrieben zu sein, die einfach blind aus anderen Sprachen bekannte Paradigmen auf Python zu übertragen, ohne sich vorher detailliert mit den Konzepten von Python beschäftigt zu haben. Im Falle des Galileo Openbooks sieht man ziemlich deutlich, dass der Autor wohl von Java kommt.

lunar hat geschrieben:Nun, die Verwendung von __slots__ zur Steuerung der Attributzugriffe ist immer der falsche Ansatz, weil __slots__ dafür nicht gedacht ist!

Das Überscheiben von __[gs]etattr__ zur Zugriffssteuerung ist im mindesten fraglich, da "harte" Zugriffsbeschränkung nicht zu den Konzepten von Python passt.

Ja, das habe ich nun beides - dank eurer Unterstützung - auch verstanden.

lunar hat geschrieben:Fazit: Wenn du Zugriffsbeschränkungen nutzen musst, dann ist höchstwahrscheinlich der Ansatz zur Problemlösung verkehrt.

Ich MUSS sie nicht nutzen in dem Sinne, dass es anders nicht ginge, sondern ich HÄTTE sie GERNE genutzt, weil es im konkreten Fall hilfreich gewesen wäre. Das Hauptaugenmerk lag/liegt darauf, bei versehentlich falsch notierten Attributen eine Fehlermeldung zu bekommen, um die ansonsten in solchen Fällen manchmal schwer aufzufindenden Fehler leichter ausmachen zu können.

Bis gestern nachmittag war ich ja noch davon ausgegangen, dass slots genau zu dem Zweck gedacht sind; jetzt, wo ich schlauer geworden bin und klar ist, dass Python eigentlich bewusst keine Konstruktion vorgesehen hat, um eine dynamische Ergänzung von Attributen zu verhindern, werde ich wohl auch darauf verzichten. Der Weg über __getattr__/__setattr__ hat ja - abgesehen davon, dass es nicht gerade elegant ist - auch den Nachteil, dass die Perfomance bei direkten Attributzugriffen dadurch deutlich leidet.

lunar hat geschrieben:Der Link von Trundle hat dir offenbar aber geholfen... und das war ein Link zur offiziellen Dokumentation der nächsten Python Version. Ich habe den Link zur aktuellen Doku gepostet, die zwar nicht ganz so schön aussieht, in der aber im Bezug auf __slots__ exakt das gleiche steht.

Stimmt alles. Aber Trundle hat es sich verkniffen, den Link durch einen Kommentar mit vorwurfsvollem Unterton zu garnieren ...

lunar hat geschrieben:Das wäre nicht der erste Fall eines schlechten Python Buchs.

Sicher. Ist ja auch in einigen Threads schon ausgiebig erörtert worden. Das von mir zitierte Buch habe ich in einem dieser Threads auch schon selbst schlecht gemacht - allerdings aus anderen Gründen. Dass es - zumindest an diesem Punkt - nachweislich auch inhaltlich daneben liegt, war für mich neu.

pütone hat geschrieben:Das Hauptaugenmerk lag/liegt darauf, bei versehentlich falsch notierten Attributen eine Fehlermeldung zu bekommen, um die ansonsten in solchen Fällen manchmal schwer aufzufindenden Fehler leichter ausmachen zu können.

Dafür gibt es pylint, pychecker und Unit Tests.

lunar hat geschrieben:Das wäre nicht der erste Fall eines schlechten Python Buchs. Viele Bücher scheinen von fachfremden Autoren geschrieben zu sein, die einfach blind aus anderen Sprachen bekannte Paradigmen auf Python zu übertragen, ohne sich vorher detailliert mit den Konzepten von Python beschäftigt zu haben.

Im Falle Lutz & Ascher sollte das eigentlich nicht sein. Ascher war bis vor kurzem im PSF-Vorstand bis er Leiter von Mozilla Messaging wurde. Daher verwundert so etwas um so mehr.

Aber Lutz schreibt da in sein Buch noch weitere so "tolle" Sachen, etwa dass man Fenster mit ``raw_input()`` offen lassen sollte.

lunar hat geschrieben:

pütone hat geschrieben:Das Hauptaugenmerk lag/liegt darauf, bei versehentlich falsch notierten Attributen eine Fehlermeldung zu bekommen, um die ansonsten in solchen Fällen manchmal schwer aufzufindenden Fehler leichter ausmachen zu können.

Dafür gibt es pylint, pychecker und Unit Tests.

Es gibt aber Nutzergruppen, für die so etwas nicht in Frage kommt, wie z.B. 14jährige, die mit Python die Grundlagen des Programmierens erlernen (wollen/sollen) ...

Warum kommt das für die nicht in Frage? Einige IDEs haben `pylint` und/oder `pychecker` integriert und lassen mindestens beim speichern über den Quelltext laufen, und das von Hand mal ab und zu auf zu rufen ist nun auch nicht so kompliziert.

Ich denke gerade `pylint` kann sehr gut dabei helfen guten Quelltext zu schreiben, weil auch einiges an Konventionen überprüft wird. Andererseits kann man es ziemlich weitgehend konfigurieren, falls man zum Beispiel bestimmte Meldungen nicht haben möchte, oder andere Richtlinien/Konventionen hat, was Anzahlen von Zeilen/Funktionen/Attributen usw. und Namenskonventionen angeht.

Und auch Unit Tests sollte man Anfängern näher bringen können. IMHO sollte man das auch unbedingt tun. Ich bin das sowohl aus der Schule als auch vom Studium gewohnt, dass man einen kleinen Test schreibt, der überprüft, ob das Programm auch wirklich dass tut, was es soll. In Python muss man ja nicht auf so ein "monströses" xUnit-ähnliches Rahmenwerk zurück greifen, wie in Java oder C++. Es gibt ja auch Doctests und zum Beispiel `py.test`, das eine recht geringe Hürde an "Formalien" stellt.