[Python-Dev] Re: method decorators (PEP 318)
Robert Mollitor
mollitor at earthlink.net
Sun Mar 28 18:27:19 EST 2004
On Sunday, March 28, 2004, at 04:38 PM, Skip Montanaro wrote:
>
> 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
Upon which object are the attributes set in each of the following cases?
def cm(cls,arg1, arg2) [attrs(accepts=(int, (int,float)),
returns=((int,float))), check_types, classmethod]:
pass
def cm(cls,arg1, arg2) [classmethod, attrs(accepts=(int, (int,float)),
returns=((int,float))), check_types]:
pass
classmethod(cm).foo = "abc" is currently disallowed, and if it wasn't,
we would need to somehow redirect things
so 'foo' is placed in the original 'cm' function object's __dict__, no?
Even ignoring classmethod/staticmethod, what is the docstring of 'func'
after you do
def printout(f):
def new_f(*args, **kwds):
print "Running f"
return f(*args, **kwds)
return new_f
def func(arg1, arg2) [printout]:
"""My function."""
print "Inside f"
That is, what would "help(func)" generate?
> 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?
It is easier to expand a public grammar than it is to shrink one.
Robert Mollitor
More information about the Python-Dev
mailing list