Decorator interface for cache dependencies

[benjaminjkraft]

It seems to me that it would be a lot cleaner to be able to do

@cache_function
@depend_on_foo(...)
@depend_on_bar(...)
def foobars(...):

as an additional option to the current syntax. Doing this such that the cache_function would go on the bottom should be fairly trivial; doing it so that the cache_function could go on top would be trickier but probably not too hard. This would also make caching of static and class methods look much cleaner.

[lenaqr]

[bikeshedding] What about this instead?

@cache_function([
    depend_on_foo(...),
    depend_on_bar(...),
])
def foobars(...):

Pro:

• Don't have to remember which one goes on top, or do special handling to support both.
• it's clear that cache_function and depend_on_foo are part of the same mechanism.

Con:

• Not backward-compatible, unless we name the one that accepts arguments something different, or do special handling to support both the argument and no-argument version (but this is probably easier, just check whether it's a list or a function).
• More typing.

[benjaminjkraft]

Ooh, I actually like that. Decorators that can be called either way are morally repugnant to me but I don't actually have a problem with them, and it also unlocks nice shorthand like

@cache_function([
    some_function_to_depend_on_cache,
    ModelToDependOnModel,
])

[lenaqr]

Can you elaborate on the shorthand? I'm not sure I understand.

[benjaminjkraft]

Sorry, to be clearer, I mean that cache_function would accept a list of depend_on_foos, but as a shorthand, one could pass a function or a model in that list to depend_on_cache or depend_on_model it, respectively. That's something you can't really do if they're all decorators, although it's also maybe better to be explicit anyway.

[lenaqr]

@benjaminjkraft, any comments on #9?