Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[MRG+2] Implements ducktyping to allow for alternative Memory implementations #9584
Ah, sorry, I made the wrong comment. There, we should still use sklearn.externals.joblib.Memory. What I think we should be doing here is adding a new helper in sklearn.utils.validation, called check_memory, which would validate the input, and return something with .cache. Then you only need the test there.…
On 19 August 2017 at 23:08, Kumar Ashutosh ***@***.***> wrote: In the code segment elif isinstance(memory, six.string_types): memory = Memory(cachedir=memory, verbose=0) we also check that if memory is passed as a string, we assign a Memory instance with cachedir as the string provided. Can we achieve it after removing the dependency on joblib ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz6-OqUxjt0M7NNbGEOXk7tV8EUzGjks5sZt40gaJpZM4O7xaJ> .
You need to add
check_memory in the documentation in
You need also to add an entry in the what's new.
Aug 30, 2017
added a commit
this pull request
Aug 30, 2017
I am not sure why we added string on top of joblib.Memory-like explicitly to the type info. As per the check_memory docstring:
joblib.Memory-like means that
In my mind, joblib.Memory-like was supposed to be modelled after array-like in numpy. You don't see this in numpy docstrings:
I would agree that being explicit and adding string makes it easier to use for user not familiar with joblib.Memory (in general the docstring does say what happens if a string is passed in though). I was hoping that just using
Well, we can debate it, but I strongly disagree that "joblib.Memory-like" is sufficiently helpful to a user who's never heard of joblib. If they're told they can use a string, then they might actually consider using the feature rather than saying "sounds like too much work". Besides, I find the analogy list:array :: string:Memory to be quite far-fetched. A some lists can be, essentially, cast into an array (the data is copied into a different format in memory and given a different API), but a string is not being cast as a Memory, it is being used as the primary attribute that defines a Memory. I get that there are some parallels, but I find the notion that a string is Memory-like to be unintuitive.…
On 30 August 2017 at 16:11, Loïc Estève ***@***.***> wrote: I am not sure why we added string on top of joblib.Memory-like explicitly to the type info. joblib.Memory-like means that memory can be converted into a sklearn.externals.joblib.Memory instance (typically a str denoting the cachedir) or has the same interface (has a cache method). In my mind, joblib.Memory-like was supposed to be modelled after array-like in numpy. You don't see this in numpy docstrings: parameter : array_like or list I would agree that being explicit and adding string makes it easier to use for user not familiar with joblib.Memory (in general the docstring does say what happens if a string is passed in though). I was hoping that just using joblib.Memory-like in the type info and either adding a link to check_memory function for more details or copy and pasting the same docstring around would work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz687XUZJa0BndNx5cSvAJLa49DacSks5sdP0QgaJpZM4O7xaJ> .
Makes sense but then I would change the wording in the check_memory docstring, probably so that joblib.Memory-like means "same interface as joblib.Memory".