Open sils opened 8 years ago
Thanks for the suggestion. How would you envision this cache working?
So this seems only relevant to the ChoicesCompleter to me, it would have an additional __init__
parameter that enables caching. When caching is enabled it is considered cheaper to read the cached choices from a cache than actually calculating them (related: https://github.com/kislyuk/argcomplete/pull/138, https://github.com/kislyuk/argcomplete/issues/137 btw.).
Assuming #138 gets merged one could hook up writing and loading to a file (name provided by https://pypi.python.org/pypi/appdirs/ ideally to be platform independent) to the choices
setter or the _load_choices
function (remove the lambda, put the function in a protected/private member.)
What would the cache key and expiration strategy be?
Not sure indeed about this one. The user of the library should definitely be able to influence that behaviour because it'll be tied to his needs.
OK. You're not the first person who requested this :) I'm going to think about this some more. So far I'm leaning toward building caching into CompletionFinder, not Completer, and using the full command line as the key. There are quite a few design chocies to make in how the cache should behave, especially in making sure it doesn't make the completions slower in pathological cases like slow cache I/O.
Hi,
we use argcomplete in coala (coala-analyzer.org) and getting possible values for one of our completers is actually something that takes about .5 seconds on decent systems. It would be nice if argcomplete would have a way to cache completions so that the experience of the user. Possibly you want the ability to mark a completion as not cached if it depends on others e.g.