-
Notifications
You must be signed in to change notification settings - Fork 3
Description
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.