Might be useful to rename the current variant decorator to staticvariant and have variant bind the primary variant to the variant context, e.g.:
@variants.primary
def func():
for i in range(25):
yield i
@func.variant('as_list')
def func(pfunc):
return list(pfunc())
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:
@variants.primary
def divide(x, y):
return x / y
@divide.variant('round')
def divide(x, y):
return round(divide(x, y))
Now imagine later you do:
divide_variants = divide
def divide(x, y):
divide_variants.round(x, y)
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.
Might be useful to rename the current
variantdecorator tostaticvariantand havevariantbind the primary variant to the variant context, e.g.:This would be similar to the
clsvariable inclassmethod. I'm not totally convinced it's useful, though, becauseprimarywill 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
divideis not bound in the local scope of thedivide.roundvariant, 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 thevariantdecorator likebind_primary=Falseto 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.