Robert> My point here is we may want to aim for making the information
Robert> kept on the function object itself as rich as possible and make
Robert> the "decorations" do the work of pulling information from
Robert> whatever the function "publishes".
You can do that with just the decorator syntax:
def attrs(**kwds):
def set_attributes(f):
for k in kwds:
setattr(f, k, kwds[k])
return f
return set_attributes
def func(arg1, arg2) [attrs(accepts=(int, (int,float)),
returns=((int,float))),
check_types]:
pass
Robert> ... there is a trivial workaround if we restrict the transformer
Robert> list to identifiers:
Robert> sync = synchronized(lockattr="baz")
Robert> def func [sync] (arg1, arg2):
Robert> pass
I think restricting decorators to only be identifiers would be shortsighted.
I can understand having to create workarounds for unforseen situations, but
it's clear at this point in the discussion that decorator functions might
need to accept parameters. Why not let them?
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4