use inspect instead of f.__code__

[costela]

Hi there,

Currently the decorator._produce_input_message function uses "home-grown" introspection via f.__code__.(...) to get the parameters of the method being wrapped. This doesn't work if the method has some other decorator, because the introspection tries to find the arguments of the decorator, instead of the decorated method.

Here's a simple example:

from functools import wraps

def deco(f):
	@wraps(f)
	def wrapped(*args, *kwargs):
		return f(*args, **kwargs)
	return wrapped

class SomeService(ServiceBase):
	@rpc(Unicode)
	@deco
	def someAction(ctx, some_argument):
		pass

Using inspect.signature(f) instead of reading f.__code__ might be a nice way to work around this problem.

[plq]

https://stackoverflow.com/questions/38198523/how-to-use-multiple-decorators-with-spyne

[costela]

My concrete case is about abstracting common behaviour across multiple RPC methods. Especially the case where some common pre-processing has to be done to structures that are then used inside the methods. Event handlers don't seem like like a good match for this case. The call_wrapper idea hadn't occurred to me though. It might be a nice solution. Will test it later.

Though I must say I'm still under the humble impression that the proposed patch in #539 is a slight improvement: this way only people that use the "broken" python2 are forced to install the decorator module, leaving py3 users free to use only built-in decorator facilities. After all, py2's days are counted! :wink: But of course: in the end it's your call.

[plq]

My concrete case is about abstracting common behaviour across multiple RPC methods. Especially the case where some common pre-processing has to be done to structures that are then used inside the methods. Event handlers don't seem like like a good match for this case.

They are designed for this exact purpose: doing preprocessing before running the main method. Authorization checks, data sanitization, etc.

Though I must say I'm still under the humble impression that the proposed patch in #539 is a slight improvement

Well... ok you got a point. I'm swamped by work at $DAYJOB atm but I'll try to find the time to review it.