havok2063/fuzzy_types

Support for function callback

Opened this issue · 3 comments

I've been using the fuzzy_types repo for the last month and I'm really loving it. One thing I've noticed though is that I need to log instances when the fuzzy match is less than 100. I've implemented this by monkey patching the __getitem__ method of FuzzyBaseDict to log to the console for now.

I think it would be great if the user could pass a callable to any of the FuzzyTypes and that callable would have a standard signature .Then the user could execute any arbitrary code (e.g the logger) when a perfect match isn't found. I forked the repo and got a barebones version of this working rather quickly for FuzzyDict. I'd be happy to polish it up and submit a P.R if you like.

If all that's needed is to log bad fuzzy matches, it might be simpler just to implement a package logger, that can log to the console or file. Can you post an example of something you had in mind for a callable besides a logger? Are you thinking about a callback that would serve as a fallback when no matches can be found? Something like that could be useful. I'm not super keen on allowing execution of any arbitrary code. That said, all the fuzzy logic is contained in get_best_fuzzy, which can be already be overridden by a user supplied function, so maybe it's not a big deal.

Sure, go ahead and submit a PR. I think any solution should be applicable to any fuzzy type, not just in FuzzyBaseDict, so we might want to move your logic higher up the object structure or possibly into the underlying get_best_fuzzy utility function.

Since my use case was specific to logging that is what I had in mind when I opened the ticket, although your idea of a fallback does sound good (albeit I don't know what a good fallback would be. That would be for other users to figure out I guess). I think a general logger for the package is probably the best idea.

I'm still interested in the callback idea so I may toy with it when I get a minute.

Also do you have a preferred formatting convention. Black is my default and I don't want to submit a PR with 100's of lines changed because they got a different format.

Yeah I'm not sure if there's really much need for a callback. Right now the code raises a ValueError when it can't find a good match. I think the standard best practice would be to catch the error in any user code and then do something with it. I can't think of an obvious use case beyond that. I think I'll add a logger anyways regardless of the callback solution.

I use linters while I'm coding so things should mostly be formatted to pep standards. I don't often run black on my code but it should be mostly consistent with black formatting. I prefer a line length of 100 and a few other idiosyncrasies, but other than that it should mostly be standard.