Skip to content

Inject the primary variant into the variant context? #24

@pganssle

Description

@pganssle

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions