New option in decorator to prepend positional arguments

[smarie]

This still needs a review and possibly improvements (such as also removing arguments by name and adding tests). Nevertheless it shows how it could be done.

Fixes #55

[micheles]

I am in doubt about this pull request, since it goes against the philosophy of the decorator module: its goal is to preserve the signature, not to change it. Having said that, I recognize that there are use cases where it would be handy to add extra arguments (I have one myself), so I am in doubt. What kind of syntax do you have in mind? Something like this?

@add_argument('request')
def func(arg1, arg2):
    ....

I would like to see the examples you have in mind.

[smarie]

I agree that this is not in the original philosophy of decorator module, but rather a "goodie" leveraging the fact the function maker capability.

The use case I have in mind was presented in #55, but it seems that I selected an overly complex one, making it a bit hard to catch. I added a simpler one in the thread, that will hopefully clarify the need.

[smarie]

As mentioned in #55, I updated the PR so that the behaviour is consistent for users, whatever the case (if additional_args contain arguments that are present in f, or not)

[micheles]

I thought a lot about this patch, but there are 150 lines of changes - in a module which is meant to be small - for a functionality which is actually against the goal of preserving the function signature. So for now I am closing this PR. I may change my mind in the future, but for the moment I prefer to keep things simple.

[smarie]

No problem ! I understand.

For future reference this mod is used in

• https://github.com/smarie/python-pytest-harvest/blob/master/pytest_harvest/decorator_hack.py#L182
• https://github.com/smarie/python-pytest-steps/blob/master/pytest_steps/decorator_hack.py#L182
• https://github.com/smarie/python-pytest-cases/blob/master/pytest_cases/decorator_hack.py#L216

so let me know if you change your mind :)

[smarie]

I had some afterthought about this: as you rightfully explained on the issue page, the problem is that I try to use only the function maker part, but not in the context of decorating functions to reach identical signature - rather to create new functions with possibly different signatures.

For this reason maybe it would be better to create an independent library with the purpose to generate functions dynamically, whatever they are. There would be several ways to specify the desired signature, for example

• providing a string containing code
• providing a Signature object, potentially acquired by inspecting another function

Decorators would then only be a specific case of usage of this lib. What would you think of this ? I will experiment to see if I can provide an illustration of what I have in mind.

[micheles]

I have no issues if you publish a new library with the new features you have in mind. The decorator module has a BSD license, so you have very few obligations to fullfill.

[smarie]

Thanks for the feedback! Ok then, I started something here, we'll see how that can go.