You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 xX 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?
The text was updated successfully, but these errors were encountered:
Right now the names are captured in the Signature, not the param.
But this is valid too
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 namedx
X
orinput
depending on context. That would maddening. And that can be modeled inautosig
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 usualAnd this is no longer valid
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 justParam
objects where the name is now mandatorymeans
Good idea, bad idea?
The text was updated successfully, but these errors were encountered: