[Python-Dev] Re: method decorators (PEP 318)

[Robert Mollitor]

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