nur Methoden und da auch nur die, die der Entwickler in einem Dict festlegt.
Hier nochmal der eigentliche Anlass bzw die Grundidee als Skizze:
Der Entwickler schreibt eine Klasse:
und Kann dann ueber die Protector Klasse
einfach seine Methoden schützen.
Code: Alles auswählen
import Protector
class A(object):
def __init__(self):
self.a = None
self.b = None
# soll dann bedeuten
# schuetze (wraped) die Methode b_method und prüfe auf admin
# wenn ok wird b_method ausgeführt, sonst eine Exeption geschmissen.
Protector.lock ( { "b_method" : "admin" } )
def a_method(self):
#irgendwas
pass
def b_method(self):
#irgendwas anderes
pass
was lock wirklich macht ist dann abhaengig vom der Implementierung
der Klasse Protector. Erster Bedarf ist Authentifizierung (und Authorisierung).
Protector soll dann ein plugin fuer PoW sein das durch Austausch der Klasse ersetzt werden
kann. Also möglichst lose gekoppelt.
Ich finde den Call einer Lock Methode an einer Stelle (fuer den Entwickler) schoener
und übersichtlicher als jede Einzemethode mit einem Dekorator verzieren zu muessen.
Da sieht man auch später auf einen Blick was in der Klasse geschützt ist und
wie.
Ich moechte das Wrappen dann auch gerne für 'dynamische' pre und post filter
nutzen. Also wie Stefan schon schrieb. Dann habe ich ein Verfahren, was ich prima fuer
mehrere Zwecke einsetzen kann.
Wie das bei Stefan und EyDu schon rueberkam gibt es da aber eben einige Moeglichkeiten
die syntaktisch verschieden sind. Ich moechte natuerlich gerne ein 'richtiges/gutes'
bzw bewaehrtes nehmen.
Ich werde mich jetzt nochmal verstaerkt mit
collections.callable und inspect befassen. Damit ich verstehe was passiert.
Dein Stichwort mit Basisklassen bzw EyDus collections geben einen guten Anstoss.
@EyDu: Bis Dahin werde ich auf deinen Vorschlag hasattr(x, "__call__") umschwingen, da das
aus meinem Zweizeiler einen Einzeiler macht. Ich wäre ja blöd wenn ich das nicht mitnähme
