unveränderbares Klassenattribut erstellen

[Goswin]

Da ich Python (wie immer) falsch verstehe, definiere ich Klassenatribute so:

Code: Alles auswählen

class Musterklasse:
   version = '0.2.3 buggy'

  
   

#Anwendercode:
print(Musterklasse.version)

#aber folgendes soll dem Anwender streng verboten sein:
Kl.version = '1.2.3 prima'
print(Musterklasse.version)

Das Klassenattribut soll jedermann zugänglich und gleichzeitig absolut unveränderbar sein. Mit 'properties' kriegt man das offenbar nicht hin, da kracht es überall.

[BlackJack]

@Goswin: An der Stelle scheinst Du schon wieder gegen die Sprache zu programmieren. Wenn Dir die inheränten Eigenschaften einer dynamischen Programmiersprache nicht gefallen, warum verwendest Du dann eine? Dein Problem löst man, in dem man der Namenskonvention folgt und klar macht, dass es sich um ein Attribut handelt was an einen konstanten Wert gebunden wird:

Code: Alles auswählen

class Musterklasse(object):
    VERSION = '0.2.3 buggy'

Jetzt ist klar, dass dieses Attribut nicht neu zugewiesen werden soll. Wenn Dir das nicht reicht und Du zusätzlich im Code weiterhin so Sachen machst wie mit `isinstance()` „statische” Typprüfungen durchzuführen, dann willst Du nicht in Python programmieren. Echt nicht.

[pillmuncher]

@Goswin: Doch, man bekommt es schon mit Properties hin:

Code: Alles auswählen

class MetaThing(type):
    @property
    def version(self):
        return '0.2.3 buggy'

class Thing(metaclass=MetaThing):
    pass

print(Thing.version)

Properties sind Eigenschaften der Klasse, nicht des Objekts. Klassenproperties sind folglich Eigenschaften der Klasse einer Klasse, mithin der Metaklasse.

Ansonsten bin ich derselben Meinung wie BlackJack, auch wenn ich es nicht ganz so streng formulieren würde. Wozu benötigst du denn Nicht-Überschreibbarkeit? Genügt es nicht, das Attribut einfach nicht zu überschreiben?

[Sirius3]

zu streng verboten fällt mir immer Java ein. Es mag ja für den Puristen eine Befriedigung sein, bestimmte Methoden protected oder sogar private zu deklarieren und für OpenSource-Packete hält sich der Aufwand auch noch einigermaßen in Grenzen sich seine Freiheiten zu schaffen, wenn man aber dann ganze Klassen nachprogrammieren muß, weil sie von außen nicht zugänglich sind und man auf anderem Weg die Bugs nicht geradebügeln kann, dann ist das nicht nur nervig, sondern kostet auch einen ganzen Nachmittag, an dem man mit seinem Projekt eigentlich viel weiter kommen wollte.

properties sind nicht dazu da, Konstanten in Python zu simulieren, sondern um den Nutzer der Klasse einen intuitiven Attributzugriff zu gestatten, im Hintergrund aber kompliziertere Operationen ablaufen zu lassen.

Es ist nicht Deine Aufgabe, den Anwender zu erziehen. Mach es ihm so bequem wie möglich und er wird, so lange er es nicht für nötig hält, sich an Deine Vorgaben halten. Kann er aber etwas nicht wie gewünscht mit Deinen Klassen erledigen, wird er Mittel und Wege finden an sein Ziel zu kommen und sei es Konstanten zu überschreiben.


@pillmuncher: oh, jetzt muß ich die version-Property der Metaklasse überschreiben, wenn ich die Version ändern will...

[Goswin]

Es ist nicht Deine Aufgabe, den Anwender zu erziehen.

Schön wäre es, aber nein: der Anwender bin ich selber .

Jetzt muß ich die version-Property der Metaklasse überschreiben, wenn ich die Version ändern will...

Das ist ok und für mich das kleinere Problem. Wenn ich schon eine gesamte Klasse umschreibe, dann wird eine einzelne Zeile mehr wohl keine Katastrofe sein.

[snafu]

zu streng verboten fällt mir immer Java ein. Es mag ja für den Puristen eine Befriedigung sein, bestimmte Methoden protected oder sogar private zu deklarieren und für OpenSource-Packete hält sich der Aufwand auch noch einigermaßen in Grenzen sich seine Freiheiten zu schaffen, wenn man aber dann ganze Klassen nachprogrammieren muß, weil sie von außen nicht zugänglich sind und man auf anderem Weg die Bugs nicht geradebügeln kann, dann ist das nicht nur nervig, sondern kostet auch einen ganzen Nachmittag, an dem man mit seinem Projekt eigentlich viel weiter kommen wollte.

Also mit ein paar schmutzigen Reflection-Tricks sollte man grundsätzlich an jedes beliebige private Objekt kommen. Ich selbst habe erst vor wenigen Monaten erfolgreich in dieser Hinsicht herumexperimentiert. Kann natürlich sein, dass die Patch-Orgie der letzten Wochen irgendwas daran verändert hat. Müsste man halt mal ausprobieren.

Grundsätzlich hast du aber natürlich Recht: Es ist ätzend, wenn der Autor einer Bibliothek meint, er müsse den Anwender besonders vor sich selbst schützen und Geheimniskrämerei betreiben und damit für manch einen vielleicht doch interessanten Code (auf herkömmlichem Wege) unzugänglich für Wiederverwendungen zu machen (Copy&Paste mal ausgenommen). Aber das ist halt der Java-Way (so wie es der Python-Way ist, gerade dies *nicht* zu tun)...

[BlackJack]

@snafu: Er schreibt ja auch die Datentypen mit in die Namen und macht Typtests weil er sonst mit der Sprache nicht klar kommt und versucht die falschen Sachen mit den Objekten zu machen. Python ist einfach nicht die richtige Sprache in diesem Fall. Wenn man eine statisch typisierte, discipline & bondage Sprache braucht/haben möchte, dann sollte man eine solche Sprache nehmen. Ist ja nicht so, dass es die nicht gäbe. Man muss dazu nicht eine dynamische Sprache hernehmen und von Hand versuchen eine statische zu emulieren. Ich finde das ein bisschen pervers.

Edit: Und gerade beim letzten Beispiel sollte man vielleicht überlegen ganz die Finger vom Programmieren zu lassen. Wenn man es nicht selber bei *eigenem* Quelltext hinbekommt Konstanten mit einer über mehrere Sprachen üblichen Konvention, durch komplette Grosschreibung des Namens, als solche zu kennzeichnen und dann eben ganz einfach *nicht neu zuzuweisen*, dann hat man echt ein gravierendes Problem.

[snafu]

@Goswin: Wozu brauchst du das eigentlich? Das einzige, was ich mir vorstellen könnte, wäre eine Vererbungsstruktur, in der man nicht versehentlich das Versionsattribut der Superklasse überschreiben soll. In diesem Fall fände ich ein Property sogar ganz in Ordnung. Könnte man dann so machen (wie ja eigentlich schon in anderer Form gezeigt wurde):

Code: Alles auswählen

class BaseType(object):
    def __init__(self):
        self._version = None

    @property
    def version(self):
        return self._version

    @version.setter
    def version(self, value):
        if self._version is not None:
            msg = 'cannot overwrite existing version value'
            raise AttributeError(msg)
        self._version = value

EDIT: Wobei mein "ganz ok" jetzt eher darauf bezogen war, dass dies ein Anwendungsfall wäre, wo man einen Grund hätte, Dinge vor Überschreiben zu schützen - jedoch nicht vor allgemeinem Schreibzugriff (denn einmal wäre hier ja erlaubt). Ob es eine Situation gibt, in der die o.g. Anforderung überhaupt Sinn macht, sei mal dahingestellt.

[snafu]

Achso, und bezüglich Java nochmal: Ich finde es jetzt nicht so wild, zwischen öffentlicher Schnittstelle und Implementierungsdetails zu unterscheiden. Was halt meiner Meinung nach Mist ist (sehe das allerdings mit Python-Vorgeschichte), ist die übermäßige Verwendung des `private`-Modifikators. Man kann oft genug stattdessen `protected` nutzen und damit die potenzielle Gebrauchstauglichkeit einer Klasse für die "Nachwelt" erhöhen. Selbst wenn man der Meinung ist, man müsste vorsorglich jegliche Instanzattribute, die eigentlich zur öffentlichen Schnittstelle gehören, kapseln (da es etwas äquivalentes zu Pythons `property` in Java ja leider nicht gibt), so könnte man IMHO immer noch die auszuliefernden Instanzattribute als `protected` deklarieren (EDIT: Wobei hier natürlich nicht das Hauptproblem liegt, da diese Attribute ja gerade über ihre Setter von außen erreichbar sind).

Aber gut, das Python-Forum ist wohl nicht wirklich ein geeigneter Ort, um sowas zu diskutieren. ^^

[Goswin]

@pillmuncher:

Vielen Dank, du hast mir *sehr* weitergeholfen: zum erstenmal seit ich programmiere lerne ich etwas über Metaklassen, bisher kannte ich sie nur vom Hörensagen. Nicht dass ich sie bereits ganz verstanden habe (das wird noch einige Zeit dauern), aber ich kann den Code schon einmal so eintippen und es funktioniert wirklich!


Natürlich interessiere ich mich nur nebenbei für so etwas einfaches wie eine Versionsnummer; es geht mir derzeit um Namedtuples, und (wenn wir übergenau sein wollen) um eine komplexe Datenstruktur wo die Namedtuples ihrerseits wiederum Namedtuples enthalten können (ja, vielleicht wären mutierbare "Namedlists" besser). Folgende Variante dieses Themas (die ebenfalls größtenteils funktioniert hat) ist freilich noch etwas verbesserungswürdig:

Code: Alles auswählen

from collections import namedtuple

class metaKl(type):
   @property
   def PersonTpl(self):
      return namedtuple( "PersonTpl", "vorname name geburtstag" )

class Kl(metaclass=metaKl):
   @property
   def PersonTpl(self): return Kl.PersonTpl.__doc__  #greift nicht


#Anwendercode
try: Kl.PersonTpl = namedtuple( "PersonTpl", "name steuernummer" )
except: print("Umdefinition von \"Kl.PersonTpl\" wurde ignoriert")

print()
kl = Kl()
kl.person = Kl.PersonTpl('Geo','Mondmann',19690720)
#kl.person = kl.PersonTpl('Geo','Mondmann',19690720) #Fehler, aber kann damit leben

print(Kl.PersonTpl) #UNBRAUCHBAR, sollte Inhalt von Kl.PersonTpl.__doc__ ausgeben
print(kl.person) #gut
print(kl.person.name) #ausgezeichnet

NACHTRAG: copy-paste-Fehler entfernt

[Goswin]

eine Vererbungsstruktur, in der man nicht versehentlich das Versionsattribut der Superklasse überschreiben soll. In diesem Fall fände ich ein Property sogar ganz in Ordnung.

Danke, das ermutigt mich

Wie in meinem vorherigen Beitrag bereits angedeutet, ist meine Klasse eine Datenstruktur mit Namedtuples welche Listen enthalten welche wiederum Namedtuples enthalten (ich tue dir sicher etwas Gutes, wenn ich dich mit den Einzelheiten verschone). Dank der zwischengeschobenen Listen ist das Ganze wenigstens teilweise mutierbar. Ich bin aber fern davon, zu behaupten, dass ich die bestmögliche Umsetzung dafür gefunden habe.

[Goswin]

Lieber BlackJack!

Wir beide ticken dermaßen verschieden, dass ich dir nur empfehlen kann, meine Anfragen schlichtweg zu ignorieren. Ich glaube wirklich, das ist besser für deine Nerven.

[snafu]

@Goswin: Sowas wie grundsätzlicher Attributschutz vor Veränderungen ist ein Python einfach total ungewöhnlich. Dieser Meinung sind außer BlackJack noch viele andere Python-User (mich inbegriffen). Wenn ein Benutzer meint, er muss ein Attribut "mutwillig" verändern (wobei das meist nur in der Theorie passiert, wo man unbedingt alle Eventualitäten einplanen möchte), dann muss er auch mit den Konsequenzen leben - ganz einfach. Falls einem das nicht passt, dann sollte man wirklich über den Wechsel zu einer anderen Sprache nachdenken, die dieses Konzept unterstützt. Ich schließe mich da vollkommen der Meinung von BlackJack an.

Du solltest dich einfach daran gewöhnen, dass die nachträgliche Veränderung von Instanzattributen zwar durchaus möglich ist, aber im Prinzip nur selten angewendet wird. Variablen zur Verwendung durch die Klasse übergibt man üblicherweise an `__init__()` und beschränkt sich ansonsten in den meisten Fällen auf lesende Zugriffe.

Wo liegt denn - abgesehen davon, dass es *theoretisch* sein könnte, dass irgendjemand Instanzattribute verändert - deine konkrete Sorge? Ich hatte ja das Beispiel mit den Versionen konstruiert (was ich eigentlich schon wieder bereue). Welches Beispiel hättest du, wo eine *unbeabsichtigte* Veränderung stattfinden könnte?

[pillmuncher]

@Goswin: ich habe keine Ahnung, was du mit deinem Code erreichen möchtest, aber du arbeitest dermaßen gegen die Sprache (d.i. Python), dass du wenig Erfolg und Freude haben wirst. Warum willst du mit aller Gewalt Sachen auf eine Weise bauen, die dir die Implementation erheblich erschweren, statt Python so zu verwenden, wie es gedacht ist?

Um das tun zu können, benötigt man allerdings zB. ein gewisses Verständnis davon, was Objektorientierung ist, wozu sie erfunden wurde und welche Probleme sie lösen soll. Deinen Klassen sieht man deutlich an, dass du dich damit noch nie beschäftigt hast. Das solltest du schnell nachholen. Ich empfehle dazu dieses Buch. Es setzt zwar Grundkenntnisse in Java voraus, aber die sind an einem Wochenende leicht soweit erlernbar, dass man damit das Buch durcharbeiten kann. Übrigens habe ich die englische Version verlinkt, da ich die deutsche nicht empfehlen kann, weil ich sie nicht gelesen habe und nicht weiß, wie gut die Übersetzung ist.

Ganz allgemein gesprochen: Programmiersprachenerfinder sind idR. ziemlich gescheite Leute, die Programmiersprachen nicht einfach nur so ins Blaue hinein entwickeln, weil ihnen langweilig wäre oder weil sie eines Morgens aufwachen und denken "heute ist ein guter Tag, um eine neue Programmiersprache zu erfinden". Im Gegenteil, sie arbeiten regelmäßig viele Jahre an verschiedenenen Sprachen, entdecken dabei Probleme, und versuchen im Anschluss an diese Entdeckungen ein konsistentes Programmiermodell zu entwickeln, das diese Probleme löst und dessen Konkretion dann eben die von ihnen erfundene Sprache darstellt. Daher ist es sinnvoll, das hinter einer Sprache stehende Programiermodell verstehen zu lernen, statt einfach irgendein selbstausgedachtes auf eine bestehende Sprache aufzupropfen und dann permanent gegen Wände zu laufen, weil das, was man gemäß dem selbstausgedachten Modell tun will, in der Sprache nicht leicht zu verwirklichen ist. Genauso könnte man versuchen, englische Worte mit spanischer Grammatik zu verbinden, nur um sich hinterher zu wundern, dass einen weder Englisch- noch Spanisch-Sprecher richtig verstehen. Oder zu versuchen auf einer Piccoloflöte Rythmusgitarrenparts zu spielen. Oder mit Wachsmalkreiden Ölbilder zu malen.

[BlackJack]

@Goswin: Also ich habe nicht verstanden was Du eigentlich machen willst. Quelltextbeispiele die überhaupt nicht funktionieren, helfen da auch nicht weiter. Das ist ja schon syntaktisch falsch.

Und semantisch ist der Teil der korrekt wäre, vorsichtig ausgedrückt komisch. `metaDatensaetze.PersonTpl` erzeugt immer neue Typobjekte, die aber allesamt gleich sind und sich gleich verhalten. Warum werden die also immer neu erstellt? Das macht keinen Sinn.

Bei `Aufgabenstellung.PersonTpl` bekommt man einen `NameError` denn `Kl` ist nirgends definiert. Dementsprechend stellt sich die Frage was der Kommentar bedeuten soll. Was greift nicht?

Beim Anwendercode ist wieder die Frage was `Kl` ist und wo das her kommt.

Ich habe so ein bisschen das Gefühl Du willst die Sprache zu etwas verbiegen was einfach nicht vorgesehen ist. Wenn ein Attribut eines Objekts eine (ungebundende) Methode ist, dann kann dieses Attribut nicht *gleichzeitig* eine Zeichenkette mit Dokumentation sein. Du musst Dich da für eines von beiden Entscheiden.

Was ist an folgendem Quelltext auszusetzen, der einfach nur ganz direkt das macht, was ich *glaube* was Du da sehr komisch versuchst umzusetzen?

Code: Alles auswählen

from collections import namedtuple


class Aufgabenstellung(object):
    PersonTpl = namedtuple('PersonTpl', 'vorname name geburtstag')
    
    def __init__(self):
        self.person = None


def main():
    aufgabenstellung = Aufgabenstellung()
    aufgabenstellung.person = Aufgabenstellung.PersonTpl(
        'Geo', 'Mondmann', 19690720
    )
    print Aufgabenstellung.PersonTpl.__doc__
    print aufgabenstellung.person
    print aufgabenstellung.person.name

Direkt, einfach, ohne irgendwelche Metamagie.

Falls der `Tpl`-Zusatz für „template” stehen sollte, ist der überflüssig. `namedtuple` erzeugt einen Datentypen und Datentypen sind grundsätzlich so etwas wie Vorlagen für konkrete Objekte. Dass es sich bei dem Objekt um einen Typ/eine Klasse handelt sieht man schon an der Namensschreibweise `Person`. Genau dafür sind solche Konventionen ja da. Und ob man einen Datentyp der ein Attribut eines Objekts ist, aus versehen umdefinieren kann, wage ich zu bezweifeln.

[Goswin]

Ich empfehle dazu dieses Buch. Es setzt zwar Grundkenntnisse in Java voraus., aber die sind an einem Wochenende leicht soweit erlernbar, dass man damit das Buch durcharbeiten kann.

Ich habe Grundkenntnisse (keine Programmiererfahrung) in Java, und das von dir empfohlene Buch habe ich vor einigen Jahren überflogen. Ich habe es dann beiseitegelassen, weil viele Konzepte, auf welche das Buches großen Wert legt, in Python nicht realisierbar sind, insbesondere Kapselung und Interfaces . Ja ich würde ohne Übertreibung sagen, dass meine von euch so empfundene "Python-feindliche" Einstellung ihren Ursprung in *genau diesem Buch* hat, vorher war ich da (als ehemaliger Fortran-Programmierer) viel lockerer. Deshalb wundert es mich echt, dass dieses Buch von einem Python-Anhänger empfohlen wird.

[pillmuncher]

@Goswin: Die zentralen Konzepte des Buchs sind leicht auf Python übertragbar. Hier ein Beispiel für das Observer-Pattern in Python (das erste Pattern im Buch ist auch das Observer-Pattern):

Code: Alles auswählen

class FooBarObservable:

    def __init__(self):
        self._observers = set()
        self._foo = 0
        self._bar = 0

    def register(self, observer):
        self._observers.add(observer)

    def remove(self, observer):
        self._observers.remove(observer)

    @property
    def foo(self):
        return self._foo

    @foo.setter
    def foo(self, value):
        self._foo = value
        for each in self._observers:
            each.foo_changed(self)

    @property
    def bar(self):
        return self._bar

    @bar.setter
    def bar(self, value):
        self._bar = value
        for each in self._observers:
            each.bar_changed(self)


class FooBarObserver:

    def __init__(self, identity):
        self._identity = identity

    def foo_changed(self, observable):
        print('Observer {}: observed foo value changed to {}'.format(
            self._identity, observable.foo))

    def bar_changed(self, observable):
        print('Observer {}: observed bar value changed to {}'.format(
            self._identity, observable.bar))


server = FooBarObservable()

client1 = FooBarObserver(1)
client2 = FooBarObserver(2)
client3 = FooBarObserver(3)


server.register(client1)
server.register(client2)
server.register(client3)

server.foo = 3
server.remove(client2)
server.bar = 4

Ergebnis:

Code: Alles auswählen

Observer 1: observed foo value changed to 3
Observer 2: observed foo value changed to 3
Observer 3: observed foo value changed to 3
Observer 1: observed bar value changed to 4
Observer 3: observed bar value changed to 4

Die weiteren Patterns im Buch kann man analog dazu programmieren.

Wie man sieht, gibt es auch in Python Interfaces und Kapselung, nur gibt es diese eben nicht als explizite Konstrukte der Sprache, sondern als reine Konventionen. Ein Objekt implementiert ein Interface, sofern es bestimmte Attribute und Methoden mit bestimmten Namen und Signaturen besitzt. Das nennt man Duck Typing. Und wenn man signalisieren möchte, dass ein Attribut privat ist und von außen nicht geändert werden sollte, versieht man dessen Namen - per Konvention - mit einem führenden Unterstrich. Der Benutzer der Klasse kann dann selbst entscheiden, ob er das Risiko eingeht, etwas kaputt zu machen, indem er dieses Attribut setzt. Guido sagt dazu immer "We are all consenting adults".

[BlackJack]

An der Stelle merke ich immer gerne an, das Kapselung nicht das gleiche ist wie erzwungene Zugriffseinschränkungen. Kapselung heisst, dass man eine Schnittstelle anbietet und diese verwendet, und nicht zwingend, dass man Zugriff auf interna um jeden Preis verhindert. Wenn man Attribute als Interna oder nur lesend zu Verwenden kennzeichnet, dann hat man Kapselung betrieben. Wenn die jemand, inklusive man selber, diese Kapselung ohne guten Grund durchbricht, dann ist das IMHO ein Problem des Programmierers der wissentlich und willentlich Grenzen überschreitet, und keines der Programmiersprache.

[Goswin]

@pillmuncher:

Wenn man signalisieren möchte, dass ein Attribut privat ist und von außen nicht geändert werden sollte, versieht man dessen Namen - per Konvention - mit einem führenden Unterstrich.

Das weiß ich nicht nur, sondern habe es in allen meinen Programmen auch so gemacht, seitdem ich Python verwende, was jetzt einige Jahre her ist. Alles Gegenteilige sind Gedankenkonstrukte (aka "Hirngespinste") von einigen Mitgliedern in diesem Forum. Wenn ich Schwierigkeiten habe (und die habe ich öfters), meine Python-Programme zum Laufen zu bringen oder zu verwalten, hat das *absolut gar nichts* damit zu tun.

Aber last not least: Danke für deine Beispiele.

[BlackJack]

@Goswin: Da Du Dich gegen alle anderen Namenskonventionen so vehement sträubst, kommt einem vielleicht nicht in den Sinn, dass Du Dich an Diese hältst.