ENH: adding suggested names to ColormapRegistry missing key error

[tacaswell]

difflib.get_close_match has been in the standard library from Python 2.1

PR summary

Make use of a function in the standard library to give suggestions for missed

PR checklist

• "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines

I don't think this needs to be called out in the release notes.

[anntzer]

(We don't have to do this now; just leaving a comment as a note.) It would be nice to be able to reuse CPython's attribute suggestions algorithm, but it looks like it's not exposed externally (other than calling excepthook and parsing stderr...); see also ipython/ipython#13445 (ipython having to reimplement it).

[tacaswell]

Ah, I thought this was cpython's suggestion algorithm.

[tacaswell]

For reference, cpython appears to use Levenshtein distance (python/cpython@37494b4#diff-aad873b2c81d05628e415ef526dbd8845ebe4bf85b2d9c6d83d6cdf804b6e7b7) where as difflibe.get_close_matches uses a different (more general?) algorithm.

It looks like traceback has a (private) implementation of Levenshtein distance, but given that using private methods makes Guido sad (and makes us sad when people use our private API) we should not do that.

I think the reasonable options are:

• stick with difflib
• vendor a copy of Levenshtein distance (CPython's implementation is only 60 lines with comments)

[tacaswell]

I'm leaning to

• vendor Levenshtein
• use it in check_list

which means a bunch more work. I'll try to get back to this, but if someone wants to take this over I will not be mad!

[QuLogic]

Would that produce better results?

[timhoffm]

Yes, what's the difference? If difflib gives reasonable results. I would stick with that as "good enough" before writing/vendoring any additional code.