Better as in "more functionality" and "better designed (with more reuse)".
doc_mint has a few tools, some of which are legacy (using regular expression to parse things), and more recently using doctest module.
Recently, I added non_doctest_lines, that came from grub, which was meant to parse out non-code text (in order to make a search "engine" on it).
Before that, I had added several functions meant to support doctest_string, itself being to extract and transform doctests from docs. The intent there was to be able to generate code, based on the doctests, that was more amenable for (1) standard tests (putting return values in asserts) and (2) md documentation (putting return values in comments).
Both of these were developed independently and should be merged, along with the split_text_and_doctests, just now pushed (see issue #35). The split_text_and_doctests design is more recent and should probably be taken as a basis.
We need better doc string tools.
Better as in "more functionality" and "better designed (with more reuse)".
doc_minthas a few tools, some of which are legacy (using regular expression to parse things), and more recently usingdoctestmodule.Recently, I added
non_doctest_lines, that came fromgrub, which was meant to parse out non-code text (in order to make a search "engine" on it).Before that, I had added several functions meant to support
doctest_string, itself being to extract and transform doctests from docs. The intent there was to be able to generate code, based on the doctests, that was more amenable for (1) standard tests (putting return values in asserts) and (2) md documentation (putting return values in comments).Both of these were developed independently and should be merged, along with the
split_text_and_doctests, just now pushed (see issue #35). Thesplit_text_and_doctestsdesign is more recent and should probably be taken as a basis.Know relevant modules
grub.pycode
test2doc.doctest_utils
┆Issue is synchronized with this Asana task by Unito