On 17 juil, 16:57, mk <mrk...@gmail.comwrote:
It seems like getter is defined in such way that it passes only 'self':
class FunDict(dict):
def __init__(self):
self.fundict = dict()
What's the use of inheriting from dict here ???
def fget(self, fun):
wrong signature for a property.fget callback
return fundict[fun.func_name]
def fset(self, newfun):
self.fundict[newfun.func_name] = newfun
newfun = property (fget, fset)
>>a=FunDict()
>>>
>>a.newfun=f1
>>>
>>a.newfun('f1')
Note that you're passing a string, when your (incorrect) getter
expects a function object.
Traceback (most recent call last):
File "<pyshell#67>", line 1, in <module>
a.newfun('f1')
TypeError: fget() takes exactly 2 arguments (1 given)
Is it possible to pass more than one argument to fget function?
Yes : call it directly !-)
Or remember the old saying:
"""
Any software problem can be solved by adding another layer of
indirection. Except, of course, the problem of too much indirection.
"""
Steve Bellovin of AT&T Labs
Applied to your problem, it would mean making your getter return a
closure that will take the func or func name and return the result of
the lookup, ie:
def fget(self):
return lambda funcname: self.fundict[funcname]
But anyway: this is still a typical case of arbitrary
overcomplexification. A plain dict would be enough. Or, given the
context (as exposed in an earlier post here), I'd suggest something
like:
class CallbacksRegister(object):
def __init__(self, **kw):
self._store = dict(**kw)
def register(self, func, name=None):
if name is None:
name = func.__name__
self._store(name) = func
return func
def get(self, name, default=None):
return self._store.get(name, default)
def __getattr__(self, name):
try:
return self._store[name]
except KeyError:
raise AttributeError('%s object has no attribute '%s'" %
(self, name)
callbacks = CallbacksRegister()
@callbacks.register
def f1(arg):
print "f1", arg
callbacks.f1("yadda")
callbacks.get('f1')('yadda')
I know: I can define a function with property name ('newfun' in the
example) and call it with more arguments. But then I do not get the
benefits of setter and property in general!
The benefit of computed attributes (the property class being only one
possible implementation) is to decouple interface (looks like an
ordinary attribute) from implementation (is in fact computed). And the
benefit from this decoupling is that you don't have to write getters/
setters until you really need them, since you can then turn a plain
attribute into a computed one without breaking the interface.
I fail to see what "benefits" you get from a property in your above
snippet.
