improve docs for fuzzywuzzy.process #68
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The documentation for this module was dated and sometimes inaccurate. This overhauls the docs to accurately describe the current module, including detailing optional arguments that were not previously explained - e.g., limit argument to extract(). This change follows the Google Python Style Guide, which may be found at: <https://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Comments#Comments>
nathantypanski
added a commit
to nathantypanski/fuzzywuzzy
that referenced
this pull request
Nov 30, 2014
Previously, process.extract expected lists or dictionaries, and tested
this with isinstance() calls. In keeping with the spirit of Python (duck
typing and all that), this change enables one to use extract() on any
dict-like object for dict-like results, or any list-like object for
list-like results.
So now we can (and, indeed, I've added tests for these uses) call
extract() on things like:
- a generator of strings ("any iterable")
- a UserDict
- custom user-made classes that "look like" dicts
(or, really, anything with a .items() method that behaves like a dict)
- plain old lists and dicts
The behavior is exactly the same for previous use cases of
lists-and-dicts.
This change goes along nicely with PR seatgeek#68, since those docs suggest
dict-like behavior is valid, and this change makes that true.
nathantypanski
added a commit
to nathantypanski/fuzzywuzzy
that referenced
this pull request
Nov 30, 2014
Previously, process.extract expected lists or dictionaries, and tested
this with isinstance() calls. In keeping with the spirit of Python (duck
typing and all that), this change enables one to use extract() on any
dict-like object for dict-like results, or any list-like object for
list-like results.
So now we can (and, indeed, I've added tests for these uses) call
extract() on things like:
- a generator of strings ("any iterable")
- a UserDict
- custom user-made classes that "look like" dicts
(or, really, anything with a .items() method that behaves like a dict)
- plain old lists and dicts
The behavior is exactly the same for previous use cases of
lists-and-dicts.
This change goes along nicely with PR seatgeek#68, since those docs suggest
dict-like behavior is valid, and this change makes that true.
|
@acslater00 does this look good to you? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The documentation for this module was dated and sometimes inaccurate.
This overhauls the docs to accurately describe the current module,
including detailing optional arguments that were not previously
explained - e.g., the
limitargument toextract().This change follows the Google Python Style Guide for comments.