Code: Alles auswählen
class C(object):
def __init__(self):
self._x = -1
self._y = -1
def y(self):
self._y += 1
return self._y
@property
def x(self):
self._x += 1
return self._x
c = C()
x = c.x #was kann man hier machen?
y = c.y
print x, x, x
print y(), y(), y()
Code: Alles auswählen
class Foo(object): #ich hänge noch an 2.6 ;)
def foo(self):
return 42
x = property(foo)
f = Foo()
y = f.foo
print f.x, y()Code: Alles auswählen
>> class Foo(object):
.. x = property(lambda self: 1)
>> Foo.x.fget(Foo())
> 1Besser ist aber, es anhand der Sprachspezifikation abzuleiten bzw. zu wissen. Nix gegen probieren, aber die Grenzen einer Programmiersprache durch trial und error zu lernen erscheint mir, sagen wir mal, suboptimal.Pekh hat geschrieben:Ob es möglich ist, könntest du - für deine Implementierung des Python-Interpreters - herausfinden, in dem du diesen einfach startest und es ausprobierst.
Das geht nur wenn dass property den Wert tatsächlich von einer Methode bekommt und der Name dieser Methode aus dem Namesraum der Klasse nicht gelöscht wurde.Pekh hat geschrieben:Wenn man aber weiß, daß es sich bei der Eigenschaft nicht um ein gewöhnliches Attribut sondern um eine Property handelt, kann man eigentlich auch direkt die zugrundeliegende Methode manipulieren.
So langsam komme ich nicht mehr mit ... Mir will gerade keine Möglichkeit einfallen, warum ein Property seinen Wert *nicht* von einer Methode / Funktion bekommen sollte. Schließlich sind die Teile doch genau dafür gedacht, einen faktischen Methodenzugriff wie einen direkten Attributzugriff darzustellen?DasIch hat geschrieben:Das geht nur wenn dass property den Wert tatsächlich von einer Methode bekommt und der Name dieser Methode aus dem Namesraum der Klasse nicht gelöscht wurde.Pekh hat geschrieben:Wenn man aber weiß, daß es sich bei der Eigenschaft nicht um ein gewöhnliches Attribut sondern um eine Property handelt, kann man eigentlich auch direkt die zugrundeliegende Methode manipulieren.
Ich sehe es eher umgekehrt: Die properties (in python) sind hauptsächlich 'syntactic sugar', um nachträglich z.B. Tests/Validierungen einzubringen, anstatt immer[ (get-/set-)Methoden zu nehmen.Pekh hat geschrieben: Schließlich sind die Teile doch genau dafür gedacht, einen faktischen Methodenzugriff wie einen direkten Attributzugriff darzustellen?
Ist natürlich grundsätzlich richtig, aber der "."-operator in Python holt ja (meistens) den Namen zur Laufzeit aus einem dict, das kostet (messbar) Zeit - die man bei vielen Wiederholungen auch spürt.Pekh hat geschrieben:Und ganz ehrlich: Wenn ich anfange, Methoden aus dem Namenraum einer Klasse zu entfernen und diese dann später wieder reinzufrickeln mache ich irgendwas falsch.
Ja, das sehe ich auch so. Ich verstehe irgendwo auch den Wunsch, die Grenzen auszuloten, aber es ist halt eine sehr theoretische Problemstellung, die in der Praxis keine Bedeutung haben sollte. Wenn man es doch brauchen sollte, ist es meiner Meinung nach ein Indiz dafür, daß im Design etwas nicht stimmt. Entweder im eigentlichen Code oder im Aufbau des Tests. Oder und.b.esser-wisser hat geschrieben:Hier greift dann nur noch das "We are all consenting adults: Man nimmt nicht automatisch properties, nur weil's geht
Und wenn ich das selbe Objekt (Methode oder Attribut, egal) an eine lokale Variable binde, wird es nicht aus einem Dict geholt? Wo werden denn die lokalen Variablen verwaltet?b.esser-wisser hat geschrieben: Ist natürlich grundsätzlich richtig, aber der "."-operator in Python holt ja (meistens) den Namen zur Laufzeit aus einem dict, das kostet (messbar) Zeit - die man bei vielen Wiederholungen auch spürt.
hth, Jörg
Code: Alles auswählen
class Foo(object):
@property
def foo(self):
return self._foo
@foo.setter
def foo(self, new_foo):
self._foo = new_foo
@apply
def bar():
def get(self):
return self._bar
def set(self, new_bar):
self._bar = new_bar
return property(get, set)
def _get_baz(self):
return self._baz
def _set_baz(self, new_baz):
self._bar = new_baz
baz = property(_get_baz, _set_baz)
del _get_baz, _set_bazDer unterschied bei einem Attribut ist dass erst das Objekt aus dem lokalen namespace geholt wird und dann dass Attribut aus dem namespace des Objektes geholt werden muss. Das kostet durchaus viel Zeit.pekh hat geschrieben:Und wenn ich das selbe Objekt (Methode oder Attribut, egal) an eine lokale Variable binde, wird es nicht aus einem Dict geholt? Wo werden denn die lokalen Variablen verwaltet?
Code: Alles auswählen
class X(object):
def __init__(self, spam):
self._spam = spam
@apply
def spam():
def fget(self):
print 'get'
return self._spam
def fset(self, value):
print 'set'
self._spam = value
doc = 'some docs'
return property(**locals())Code: Alles auswählen
In [50]: def f():
....: a = 42
....: b = 23
....: print a, b, c
....:
In [51]: import dis
In [52]: dis.dis(f)
2 0 LOAD_CONST 1 (42)
3 STORE_FAST 0 (a)
3 6 LOAD_CONST 2 (23)
9 STORE_FAST 1 (b)
4 12 LOAD_FAST 0 (a)
15 PRINT_ITEM
16 LOAD_FAST 1 (b)
19 PRINT_ITEM
20 LOAD_GLOBAL 0 (c)
23 PRINT_ITEM
24 PRINT_NEWLINE
25 LOAD_CONST 0 (None)
28 RETURN_VALUEDa begeben wir uns in die 'internals' der (CPython-)VM - und damit kenne ich mich nicht wirklich aus, aber ich denke es gibt zwei Möglichkeiten:Pekh hat geschrieben: Und wenn ich das selbe Objekt (Methode oder Attribut, egal) an eine lokale Variable binde, wird es nicht aus einem Dict geholt? Wo werden denn die lokalen Variablen verwaltet?
Vielen Dank auch. Und für das damit verbundene "Problem" gibt es bestimmt auch noch einen schönen Ansatz. Aber das muß wohl von Fall zu Fall entschieden werden.