Repository navigation
Match Google and Numpydoc section titles in any case - #177
Merged
Merged
Conversation
Section titles matched only as declared, so "ARGS:", "returns:" or an underlined "PARAMETERS" stayed in the long description. Napoleon reads titles in any case, and so do both styles now. Where two declared titles differ only in case, the first declared wins. In Google, a title written in another case than declared starts a section only at the top or after a blank line, so that prose wrapped as "For" and "example:" on the next line stays prose. The text invariant now ignores title words in any case.
This file contains hidden or 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
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.
Google and Numpydoc now match section titles in any case, as Sphinx napoleon does.
ARGS:,returns:,RaIsEs:and an underlinedPARAMETERSstart their sections instead of staying in the long description. This also applies to customSectionSpectitles. If two declared titles differ only in case, the first one declared wins.In Google, a title written in a different case from its declaration only starts a section at the top of the docstring or after a blank line. Without that rule, three stdlib docstrings broke: prose wrapped as
For/example:, orprovided/arguments:, turned into a section. A title written exactly as declared works the same as before.Case diffs
numpydoc/unknown_heading_02,corpus/numpy/...can_castandcorpus/numpy/...tril_indices: an underlinedSee alsoused to be an unknown heading, a text meta withtitle: 'See also'. It is now the See Also section, so thetitleis gone and compose writesSee Also. The parse reads back the same. I reworded the case comment inunknown_heading_02to match.google/title_case_01,google/title_case_02(prose before a lowercase title stays prose) andnumpydoc/title_case_01.test_no_text_is_droppednow compares title words without regard to case. Both exclusion lists are unchanged.Parity against
origin/mainThe stdlib one is
_strptime.LocaleTime, which has an indentedATTRIBUTES:after a blank line followed byname -- textitems. The Google parser now reads it as an attributes section, and since the items have no colon it raisesParseError. Before, the whole thing went to the long description. Auto-detection still picks the same style for it.tools/parity.pyitself crashes with aKeyErrorwhen printing an input that parses in the base but not in the tree, so I got these counts from a small script that calls itsoutputs().Bench
Python 3.8, every ratio between 0.98 and 1.03.