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
This would be similar to the cls variable in classmethod. I'm not totally convinced it's useful, though, because primary will basically always just be func. There's no notion of instantiation or inheritance in functions. I think the main reason this would be useful is if you were planning on defining a variants hierarchy under one name, then you were to later assign that name, globally, to something else. Under the current version, variants referencing one another looks like this:
Since divide is not bound in the local scope of the divide.round variant, this will cause an infinite recursion. I think that this scenario is rare enough that for now users can just work around it, and maybe we can add a keyword argument to the variant decorator like bind_primary=False to enable this behavior. Still, I'm interested to hear if anyone can think of another reason why eagerly binding the primary variant would be useful in this scenario.
The text was updated successfully, but these errors were encountered:
Might be useful to rename the current
variant
decorator tostaticvariant
and havevariant
bind the primary variant to the variant context, e.g.:This would be similar to the
cls
variable inclassmethod
. I'm not totally convinced it's useful, though, becauseprimary
will basically always just befunc
. There's no notion of instantiation or inheritance in functions. I think the main reason this would be useful is if you were planning on defining a variants hierarchy under one name, then you were to later assign that name, globally, to something else. Under the current version, variants referencing one another looks like this:Now imagine later you do:
Since
divide
is not bound in the local scope of thedivide.round
variant, this will cause an infinite recursion. I think that this scenario is rare enough that for now users can just work around it, and maybe we can add a keyword argument to thevariant
decorator likebind_primary=False
to enable this behavior. Still, I'm interested to hear if anyone can think of another reason why eagerly binding the primary variant would be useful in this scenario.The text was updated successfully, but these errors were encountered: