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.

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

Should a param also determine the name? #11

Open
piccolbo opened this issue Aug 23, 2019 · 0 comments
Open

Should a param also determine the name? #11

piccolbo opened this issue Aug 23, 2019 · 0 comments

Comments

@piccolbo
Copy link
Owner

Right now the names are captured in the Signature, not the param.

X = param()
@autosig(Signature(x=X))
def fun(x) ...

But this is valid too

@autosig
def fun(y=X)

This seems inconsistent with the idea that the name is part of what makes an argument and what makes its usage consistent. Imagine pandas where the data argument is also named x X or input depending on context. That would maddening. And that can be modeled in autosig right now with signatures. But if we wanted to support name consistency in the argument-free decorator, than we could add an optional name argument to param (default being any name or business as usual

X = param(name='x')
@autosig(Signature(x=X))
def fun(x) ...

And this is no longer valid

@autosig
def fun(y=X)

There is a less known and never used form of Signature which takes pairs name, Param as var args instead of the more documented and recommended kwargs. We could drop that and let the var args be just Param objects where the name is now mandatory

sig = Signature(X)

means

Signature(x=X)

Good idea, bad idea?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant