RF: to allow for more flexible use

[yarikoptic]

For now just "thinking out loud", I guess more specifics would come as I try...

• ATM the main use pattern is to decorate a function using @cache.memoize_path under assumption that path is the first positional argument. But it might not be the case in already existing code base, thus would require either

  • creating use-case specific shims which would reorder/extract path from the corresponding function signature (could be in kwargs, or another positional arg), or even a value itself (e.g. in datalad it would be a dataset instance passed through from which we would get .path)
  • providing some convenience, e.g. path_getter(*args, **kwargs) which if not defined, would be just current default args[0]

• if a path_getter above, and whenever we make it parametrized (e.g. for support for ignoring/considering some paths #5 support for hierarchical organization / boundaries #6 account for symlinks #10 ) -- should those be defined at the class level or at memoize_path invocation level? ATM we seems (actually I am a bit confused how we account for different functions...) allow for the same cache to be used across multiple functions. So if we are to allow that, it smells that for path_getter should be at invocation level since the same cache could be used across multiple invocations (functions)

• probably there is no non-decorator use pattern we need to provide, but we need to make sure that it works if we decorate a function instance right in the code, e.g.

def func(path, ...):
     ...

def some(...):
         out = cache.memoize_path(func)(path)

or especially either it would somehow work on locally defined functions/closures like

def some(...):
    def func(path, ...):
         ...
    out = cache.memoize_path(func)(path)

and make sure that multiple invocations of some do take advantage of the cache from prior invocations

• if we do not foresee a use for __call__, should we just rename memoize_path -> __call__?