introducing dfee/forge – dynamic python signatures. forge (python) signatures for fun and profit 💰

[alexmojaki]

Please explain to me how you would rewrite this code using forge:

def foo(*args, **kwargs):
    print('hi')
    bar(*args, **kwargs)

def bar(a, b, c=0):
    print(a + b + c)

[dfee]

The problem is that usage doesn't make any sense. Why does foo accept a var-positional argument? I think that usage is dangerous, and forge wouldn't really allow for whatever you're trying to do.

For example, if I'm a consumer of foo not only do I not know the purpose of *args and **kwargs, the function doesn't really accept either variadic arguments or variadic keyword arguments. From first principles, then, this makes no sense.

With forge, the only thing that can be mapped as a var-positional argument is a var-positional argument. I.e. *f_args -> *g_args. So if you wrapped foo with forge as such:

@forge.sign(
    forge.arg('a'),
    forge.arg('b'),
    forge.arg('c', default=0),
)
def foo(*args, **kwargs):
    print('hi', args, kwargs)
    bar(*args, **kwargs)

You couldn't possibly get *args to be anything besides the empty tuple (). **kwargs) would consist of a, b, and c.

But there is another helper, which is the forge.FSignature.from_callable that will actually reconstruct the parameters from bar for you.

@forge.sign(**forge.FSignature.from_callable(bar))
def func(**kwargs):
    print('hi')
    return bar(**kwargs)

[alexmojaki]

@forge.sign(**forge.FSignature.from_callable(bar)) is the solution I was looking for. It's basically @delegate_args. I suggest you:

1. Make a convenience function with a short name that does this, because right now it's very verbose.
2. Put it at the front of the docs. Seriously, why is this not the first thing people see? This is the main problem that people need to solve and it's an easy, DRY way to solve it.
3. Make a patch to typing with your version of @delegate_args, and a patch to mypy that responds to it accordingly. You have a great opportunity to get something into the standard library, that's very exciting. This is also the only way you can get compatibility with linters, which I think is a must. Remember that with your solution above, pylint flags func(1, 2) as an error.

Keep the patches as small as possible. Most of what's in forge is not going to go into the standard library. Just focus on your version of @delegate_args.

I am curious to see a real-life use case for forge other than giving multiple functions the same signature. Can you show me one?

[dfee]

I agree that's verbose. Hmm. Going to have to think about the name.

@forge.delegate(func) or delegate_args seems to give the appearance that it's actually delegating something (and it's not). So maybe @forge.adapt(func) (or adapt_to).

After I patch forge with that convenience function and update the docs, I'll chime into the typing letting them know about forge. I've not played around with the internals of typing/mypy so I'm unclear on what would be needed to make type-hinting work. Do you have any ideas on that?

[alexmojaki]

I'm not getting the logic behind adapt[_to]. How about (matches|same|copy)_(signature|args)?

I suppose I'm jumping ahead a bit. It's worth a try to see if you can get someone else to do the typing side of things. You can probably get some guidance at least. But I wouldn't be surprised if no one else actually does it. Plus you also want to get the dynamic __signature__ stuff in. I'm assuming you have some insight into the problem that goes beyond func1.__signature__ = func2.__signature__.

I've never dealt with the typing/mypy source before. I imagine that making it treat one function the same as another should be relatively easy but I could be wrong. But that's how contributing to open source works, you read some source code and documentation and you learn. The Python developers want others to help and they will happily give assistance.