Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

use inspect instead of f.__code__ #538

Open
costela opened this issue Aug 12, 2017 · 3 comments · May be fixed by #539
Open

use inspect instead of f.__code__ #538

costela opened this issue Aug 12, 2017 · 3 comments · May be fixed by #539

Comments

@costela
Copy link
Contributor

costela commented Aug 12, 2017

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.
costela added a commit to costela/spyne that referenced this issue Aug 12, 2017
@costela
use inspect.signature for decorators
508e1d1 
fixes arskom#538
@costela costela linked a pull request Aug 12, 2017 that will close this issue
Open
costela added a commit to costela/spyne that referenced this issue Aug 12, 2017
@costela
use inspect.signature for decorators
346c1d8 
fixes arskom#538
@plq
Copy link
Member

plq commented Aug 13, 2017

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

@costela
Copy link
Contributor Author

costela commented Aug 14, 2017

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! 😉
But of course: in the end it's your call.

@plq
Copy link
Member

plq commented Aug 14, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

use inspect.signature for decorators costela/spyne
2 participants
@plq @costela